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OS  TRACT 

This  thesis  presents  an  implementation  of  process 
manage me nt  tor  a  security  Kernel  based  secure  archival 
storage  system  (SASS).  Tie  implement  ion  is  based  en  a  family 
of  secure,  distributed,  multi-microprocessor  operating 
systems  designed  to  provide  multilevel  internal  security  and 
controlled  snaring  of  data  among  authorized  users.  Frocess 
scheduling  is  effected  by  one  naif  of  a  two  level  Traffic 
Controller  tnat  binds  processes  to  virtuaiized  processors. 
Inter-process  communication  mecnanisms  for  synenronization, 
mutual  exclusion,  and  message  passing  among  processes  are 
provided  by  utilization  of  eventoount  and  sequencer 
primitives.  The  implementation  structure  is  rased  upon 
levels  of  abstraction  and  is  Loop  free  to  permit  future 
expansion  to  more  complex  members  of  tne  design  family. 
Implementation  was  completed  en  the  ADVANCED  MICRO  C0KFUTE7.S 
am  96M116  AmZ80Z2  16  rit  Monoioard  Comouter. 
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I.   INTRODUCTION 

This  thesis  addresses  the  implementation  of  process 
management  functions  for  the  Secure  Archival  Storage  System 
or  SASS.  This  system  is  designed  to  provide  multilevel 
secure  access  to  information  stored  for  a  network  of 
possioly  dissimilar  host  computer  systems  and  the  controlled 
sharing  of  data  amongst  authorized  users  of  the  SASS. 
Effective  process  management  is  essential  to  insure 
efficient  use  and  control  of  the  system. 

Among  the  major  accomplishments  of  the  work:  reported 
here  are  the  inclusion  of  provisions  for  efficient  process 
creation  and  management.  These  functions  are  provided 
through  the  establishment  of  a  system  Traffic  Controller  and 
the  creation  of  a  virtual  interrupt  structure.  An  effective 
mechanism  for  inter-process  communication  and 
synchronization  is  realized  through  an  Event  Manager  that 
maKes  use  of  uniquely  identified  segments  supported  «#>y 
eventcount  and  sequencer  primitives.  A  hardware  controlled 
two  domain  operational  environment  is  created  with  the 
necessary  interfacing  between  domains  provided  by  a  software 
"gate"  mechanism.  Additional  support  is  provided  through 
considerable  worlt  in  the  area  of  database  initialization  and 
a  technique  for  limited  dynamic  memory  allocation. 
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This  implementation  was  completed  on  the  commercial  AMC 
An96/4116  MonoBoard  Computer  witn  a  standard  Multibus 
interface . 

A.   BACKGROUND 

The  brief  history  of  digital  computers  has  been 
characterized  by  rapid  advances  in  hardware  technology  and  a 
continual  increase  in  the  number  and  variety  of  its 
applications.  The  advent  of  the  microprocessor  has  enabled 
virtually  every  level  of  our  society  to  make  use  of  computer 
resources.  Today's  "desk  top"  microcomputers,  costing  less 
than  a  thousand  dollars,  have  more  computing  power  than  the 
"giant"  computers  of  the  early  1950's  that  cost  hundreds  of 
times  that  amount. 

These  rapid  advances  in  computer  hardware  technology 
have  reversed  the  economics  of  the  computer  design 
environment.  While  hardware  costs  nave  decreased,  the 
relative  costs  of  the  software  required  to  effectively 
utilize  this  hardware  nas  steadily  increased  until  it  now 
dominates  the  overall  cost  of  a  computer  system.  This 
economic  reversal  requires  that  developed  software  be 
logical,  easy  to  read,  relatively  maintenance  free,  and  easy 
to  debug.  Unfortunately,  microcomputer  operating  systems  and 
applications  software  tend  to  be  highly  specialized,  thus 
failing  to  reasonably  exploit  the  potential  of  tne 
microprocessor. 
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As  the  usage  of  computers  has  expanded,  expeciaily  in 
the  area  of  sensitive  information  handling,  the  need  for 
information  security  has  received  greater  recognition.  While 
ad-hoc  attempts  have  been  made  to  provide  internal  computer 
security  on  larger  systems,  the  problem  of  information 
security  on  microprocessors  has  been  largely  ignored  to 
date. 

In  an  attempt  to  address  the  above  problems,  O'Conneil 
and  Richardson  [1]  outlined  a  high  level  design  for  a 
microprocessor  based  secure  operating  system.  The  goal  of 
this  design  was  to  provide  information  security,  distributed 
processing,  multiple  protection  domains,  configuration 
independence,  multiprocessing,  and  multiprogramming.  Since 
all  computer  applications  do  not  require  such  a  broad  and 
general  operating  system,  the  design  provided  for  a  family 
of  operating  systems.  This  allows  a  member  of  the  family  to 
incorporate  only  the  subset  of  family  functions  needed  for 
its  specific  application,  while  providing  for  future 
expansion.  The  SASS  is  a  member  of  this  operating  system 
family. 

A  brief  nistory  of  prior  wort  done  on  the  SASS  is  now 
provided.  Parts  [2J  provided  the  design  for  the  SASS 
Supervisor.  The  actual  implementation  of  the  Supervisor 
design  has  not  been  addressed  to  date.  The  initial  design  of 
the  SASS  Security  Kernel  was  completed  by  Coleman  [3]  .  The 
works  of  O'Conneil   and   Richardson   [1J  ,   Parts   [2J  ,   and 
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Coleman  [3]  are  available  as  a  single  publication  from  NTIS 
and  DDC  in  a  report  prepared  by  Schell  and  Cox  [21 J  .  Further 
refinements  of  tne  Kernel  design  and  partial  Kernel 
implementation  has  been  accomplished  in  three  additional 
thesis  efforts.  Moore  and  Gary  [4j  provided  the  detailed 
design  and  partial  implementation  of  the  Memory  Manager 
module.  Design  refinements  for  tne  Inner  Traffic  Controller 
and  Traffic  Controller  modules  as  well  as  implementation  of 
the  Inner  Traffic  Controller  was  provided  by  Reitz  [5]. 
Wells  [6]  provided  implementation  of  the  Segment  Manager  and 
Non-Discretionary  Security  modules  as  well  as  partial 
implementation  of  distributed  Memory  Manager  functions. 
These  design  and  implementation  efforts  provided  the  basis 
for  the  work  described  here. 

E.   BASIC  CONCEPTS/DEFINITIONS 

This  section  provides  an  overview  of  several  concepts 
essential  to  the  SASS  design.  Readers  familiar  with  SASS  or 
with  secure  operating  system  principles  may  wish  to  skip  to 
the  next  section. 

1.   Process 

The  notion  of  a  process  has  been  viewed  in  many  ways 
in  computer  science  literature.  Organic*  [7]  defines  a 
process  as  a  set  of  related  procedures  and  data  undergoing 
execution  and  manipulation,  respectively,  by  one  of  possibly 
several   processors  of  a  computer.  Madnick  and  Donovan  [Sj 
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view  a  process  as  the  locus  of  points  of  a  processor 
executing  a  collection  of  programs.  Reed  [9J  describes  a 
process  as  the  sequence  of  actions  ta&en  by  some  processor. 
In  otner  words,  it  is  tne  past,  present,  and  future 
"history"  of  the  states  of  the  processor.  In  the  SASS 
design,  a  process  is  viewed  as  a  logical  entity  entirely 
characterized  by  an  address  space  and  an  execution  point.  A 
process'  address  space  consists  of  the  set  of  all  memory 
locations  accessible  by  the  process  during  its  execution. 
This  may  be  viewed  as  a  set  of  procedures  and  data  related 
to  the  process.  The  execution  point  is  defined  by  the  state 
of  the  processor  at  any  eriven  instant  of  process  execution. 

As  a  logical  entity,  a  process  may  have  logical 
attributes  associated  with  it,  sucn  as  a  security  access 
class,  a  unique  identifier,  and  an  execution  state.  This 
notion  of  logical  attributes  should  not  be  confused  witn  tne 
more  typical  notion  of  physical  attributes,  such  as  location 
in  memory,  page  size,  etc.  In  SASS,  a  process  is  siven  a 
security  access  class,  at  the  time  of  its  creation,  to 
specify  what  authorization  it  possesses  in  terms  of 
information  access  (to  be  discussed  in  the  next  section).  It 
is  also  given  a  unique  identifier  that  provides  for  its 
identification  by  the  system  and  is  utilized  for  interaction 
amons  processes.  A  process  may  exist  in  one  of  three 
execution  states:  1)  running,  2)  ready,  and  3)  blocked.  In 
order  to  execute,  a  process  must  be  mapped  onto  (bound  to)  a 
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pnysical  processor  in  the  system.  Sucn  a  process  is  said  to 
be  in  the  "running"  state.  A  process  that  is  not  mapped  onto 
a  pnysical  processor,  but  is  otnerwise  ready  to  execute,  is 
in  the  "ready"  state.  A  process  in  tne  ""blocked"  state  is 
waiting  for  some  event  to  occur  in  tne  system  and  cannot 
continue  execution  until  the  event  occurs.  At  that  time,  the 
process  is  placed  into  tne  ready  state. 
2.   Information  Security 

There  is  an  ever  increasing  demand  for  computer 
systems  that  can  provide  controlled  access  to  the  data  it 
stores.  In  this  thesis,  "information  security"  is  defined  as 
tne  process  of  controlling  access  to  information  based  upon 
proper  authorization.  The  critical  need  for  information 
security  should  "be  clear.  Banks  and  other  commercial 
enterprises  risk  the  theft  or  loss  of  funds.  Insurance  and 
credit  companies  are  bound  by  law  to  protect  the  private  or 
otherwise  personal  information  they  maintain  on  their 
customers.  Universities  and  scientific  institutions  must 
prevent  the  unauthorized  use  of  their  often  over-burdened 
systems.  The  Department  of  Defense  and  otner  government 
agencies  must  face  the  very  real  possibility  that  classified 
information  is  being  compromised  or  that  weapon  systems  are 
being  tampered  witn.  In  fact,  security  related  problems  can 
be  found  at  virtually  every  level  of  computer  usage. 

In  tne  past,  attempts  nave  been  made  to  identify  tne 
security  weakness  of  computer  systems  by  trial  and  error  and 
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then  fix  them.  However,  Schell  [10]  has  shown  that  security 
cannot  he  "added  on"  to  an  existing  system  with  any  degree 
of  confidence  that  the  resulting  security  system  is 
impregnable.  Security  must  be  explicitly  designed  into  a 
system  from  first  principles.  The  Key  to  achieving  provable 
information  security  is  realized  in  the  concept  of  the 
"security  lrernel."  Schell  [llj  provides  a  detailed 
discussion  of  the  use  of  this  concept  in  the  methodical 
design  of  system  security. 

The  security  of  computer  systems  processing 
sensitive  information  can  be  achieved  by  two  means:  external 
security  controls  and  internal  security  controls.  In  the 
first  case,  security  is  achieved  by  encapsulating  the 
computer  and  all  its  trusted  users  within  a  single  security 
perimeter  established  by  pnysicai  means  (e.g.,  armed  guards, 
fences,  etc.)  This  means  of  security  is  often  undesirable 
due  to  its  added  cost  of  implementation,  tne  innerent  risic 
of  error-prone  manual  procedures,  and  the  problem  of 
trustworthy  but  error-prone  users.  Also,  since  all  security 
controls  are  external  to  the  computer  system,  the  computer 
is  incapable  of  securely  handling  data  at  differing  security 
levels  or  users  with  differing  degrees  of  authorization. 
This  restriction  greatly  limits  the  utility  of  modern 
computers.  Internal  security  controls  rely  upon  the  computer 
system  to  internally  distinguish  between  multiple  levels  of 
information  classification  and  user  authorization.  This  is 
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clearly  a  more  desirable  and  flexible  approach  to 
information  security.  Tnis  does  not  mean,  however,  tnat 
external  security  is  not  needed.  The  optimal  approacfi  would 
be  to  utilize  internal  security  controls  to  maintain 
information  security  and  external  security  controls  to 
provide  pnysical  protection  of  our  system  against  sabotage, 
theft,  or  destruction.  The  primary  concern  of  this  thesis  is 
information  security  and  will  therefore  center  its 
discussion  on  the  achievement  of  information  security 
through  implementation  of  the  security  kernel  concept. 

One  might  argue  that  a  "totally  secure"  computer 
system  is  one  that  allows  no  access  to  its  classified  or 
otherwise  sensitive  information.  Sucn  a  system  would  not  be 
of  much  value  to  its  users.  Therefore,  when  we  say  that  a 
system  provides  information  security,  it  is  only  secure  with 
respect  to  some  specific  external  security  policy 
established  by  laws,  directives,  or  regulations.  There  are 
two  distinct  aspects  of  security  policy:  non-discretionary 
and  discretionary.  Each  user  (subject^  of  the  system  is 
given  a  label  denoting  what  classification  or  level  of 
access  the  user  is  authorized.  Likewise,  all  information  or 
segments  (objects)  within  the  system  are  labelled  with  their 
classification  or  level  of  sensitivity.  The 
non-discretionary  security  mechanism  is  responsible  for 
comparing  the  authorization  of  a  subject  with  the 
classification  of  an  object  and  determining  what  access,  if 
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any,  should  be  granted.  The  DOD  security  classification 
system  provides  an  example  of  the  non-discretionary  security 
policy  and  is  tne  policy  implemented  in  SASS.  Tne 
discretionary  security  policy  is  a  refinement  of  the 
non-discretionary  policy.  As  sucn,  it  adds  a  higher  degree 
of  restriction  by  allowing  a  subject  to  specify  or  restrict 
who  may  nave  access  to  nis  files.  It  must  be  empnasized  that 
the  discretionary  policy  is  contained  within  the 
non-discretionary  policy  and  in  no  way  undermines  or 
substitutes  for  it.  This  prevents  a  subject  from  granting 
access  that  would  violate  the  non-discretionary  policy.  An 
example  of  discretionary  security  is  provided  by  tne  DOD 
"need  to  know"  policy.  In  SASS,  the  discretionary  policy  is 
implemented  within  the  supervisor  [2j  by  means  of  an  Access 
Control  List  (ACL).  There  is  an  ACL  maintained  for  every 
file  in  tne  system,  wnich  provides  a  list  of  all  users 
authorized  access  to  that  file.  Every  attempt  by  a  user  to 
access  a  file  is  first  cnecked  against  tne  ACL  and  then 
checked  against  the  non-discretionary  security  policy.  The 
"least"  or  "most  restrictive"  access  found  in  tnese  checks 
is  then  granted  to  the  user. 

The  relationship  between  the  labels  associated  with 
the  subject's  access  class  (sac)  and  the  object's  access 
class   (oac)   is   defined   oy  a   lattice  model   of   secure 


information   flow    [12J    as   follows   ( 
relationship" ) : 


i  *• 


denotes   no 
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1.  sac  =  oac,  read  and  write  access  permitted 

2.  sac  >  oac,  read  access  permitted 

3.  sac  <  oac,  write  access  permitted 

4.  sac  !  oac,  no  access  permitted 

In  order  to  understand  how  these  access  levels  are 
determined,  it  is  necessary  to  sain  an  awareness  of  and 
consideration  for  several  basic  security  properties. 

The  "Simple  Security  Property"  deals  with  "read" 
access.  It  states  that  a  subject  may  nave  read  access  only 
to  those  object's  whose  classification  is  less  than  or  equal 
to  tne  classification  of  tne  subject.  This  prevents  a 
subject  from  reading  any  object  possessing  a  classification 
nigher  than  nis  own. 

The  "Confinement  Property"  (also  known  as 
""'-property")  governs  "write"  access.  It  states  tnat  a  user 
may  be  granted  write  access  only  to  tnose  objects  whose 
classification  is  greater  than  or  equal  to  the 
classification  of  the  subject.  This  prevents  a  user  from 
writing  information  of  a  higher  classification  (e.e., 
Secret)  into  a  file  of  a  lower  classification  (e.g., 
Unclassified).  It  is  noted  that  while  this  property  allows  a 
user  to  write  into  a  file  possessing  a  classification  higher 
than  his  own,  it  does  not  allow  him  access  to  any  of  the 
data  in  that  file.  The  SASS  design  does  not  allow  a  user  to 
"write  up"  to  higher  classified  files.  Therefore,  in  SASS, 
"sac  <  oac"  denotes  "no  access  permitted." 
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The  Compatibility  Property  deals  with  the  creation 
of  objects  in  a  hierarchical  structure.  In  SASS,  objects 
(segments)  are  hierarcnically  organized  in  a  tree  structure. 
This  structure  consists  of  nodes  with  a  root  node  from  which 
the  tree  eminates.  The  Compatibility  Property  states  that 
tne  classification  of  objects  must  be  non-decreasing  as  we 
move  down  the  hierarchical  structure.  This  prevents  a  parent 
node  from  creating  a  child  node  of  a  lower  classification. 

Several  prerequisites  must  be  met  in  order  to  insure 

that  the  security  Kernel  design  provides  a  secure 
environment.  Firstly,  every  attempt  to  access  data  must 
invoke  the  Kernel.  In  addition,  the  Kernel  must  be  isolated 
and  tamperproof.  Finally,  tne  Kernel  design  must  be 
verifiable.  This  implies  that  the  mathematical  model,  upon 
which  the  Kernel  is  based,  must  be  proved  secure  and  tnat 
the  Kernel  is  shown  is  to  correctly  implement  this  model. 
3.   Segmentation 

Segmentation  is  a  key  element  of  a  security  Kernel 
based  system.  A  segment  can  be  defined  as  a  logical  grouping 
of  information,  sucn  as  a  procedure,  file  or  data  area  [8J . 
Therefore,  we  can  redefine  a  process'  address  space  as  the 
collection  of  all  segments  addressable  by  that  process. 
Segmentation  is  the  technique  applied  to  effect  management 
of  tnose  segments  within  an  address  space.  In  a  segmented 
environment,  all  references  within  an  address  space  require 
two  components:  1)  a  segment  specifier  (number)  and  2)  the 
location  (offset)  within  the  segment. 
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A  segment  may  nave  several  logical  and  pnysical 
attributes  associated  witn  it.  Tne  logical  attributes  may 
include  the  segment's  classification,  size,  or  permissable 
access  (read,  write,  or  execute).  Tnese  logical  attributes 
allow  a  segment  to  nicely  fit  the  definition  of  an  object 
within  the  security  kernel  concept,  and  thus  provide  a  means 
for  the  enforcement  of  information  security.  A  segment's 
physical  attributes  include  tne  current  location  of  the 
segment,  whether  or  not  the  segment  resides  in  main  memory 
or  secondary  storage,  and  wnere  tne  segment's  attributes  are 
maintained  by  a  segment  descriptor.  The  segment  descriptors 
for  eacn  segment  in  a  process'  address  space  are  contained 
within  a  Descriptor  Segment  (viz.,  the  MMU  Image  in  SASS)  to 
facilitate  tne  memory  management  of  that  address  space. 

Segmentation  supports  information  sharing  by 
allowing  a  single  segment  to  exist  in  tne  address  spaces  of 
multiple  processes.  This  allows  us  to  forego  the  maintenance 
of  multiple  copies  of  tne  same  segment  and  eliminates  tne 
possibility  of  conflicting  data.  Controlled  access  to  a 
segment  is  also  enforced,  since  eacn  process  can  nave 
different  attributes  (read/write)  specified  in  its  segment 
descriptor.  In  the  implementation  of  SASS,  any  segment  which 
is  shared,  but  has  "read  only"  access  by  every  process 
sharing  it,  is  placed  in  the  processor  local  memory 
supporting  each  of  these  processes  rather  than  in  the  global 
memory.   This   implies  the  maintenance  of  multiple  copies  of 
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some  snared  segments.  It  is  noted  tnat  tne  problem  of 
"conflicting  data"  is  avoided  since  this  only  applies  to 
read  only  segments.  Tnis  apparent  waste  of  memory  and  nonuse 
of  existing  snaring  facilities  is  justified  by  a  design 
decision  to  provide  maximum  reduction  of  bus  contention 
among  processors  accessing  global  memory.  Tnis  reduction  in 
bus  contention  is  considered  to  be  of  more  importance  tnan 
the  saving  of  memory  space  provided  by  single  copy  sharing 
of  read  only  segments.  This  decision  is  also  well  supported 
by  the  occurrence  of  decreasing  memory  costs,  which  we  have 
experienced  in  terms  of  high  speed  bus  costs. 
4.   Protection  Domains 

The  requirement  for  isolating  the  Kernel  from  the 
remainder  of  the  system  is  achieved  by  dividing  the  address 
space  of  each  process  into  a  set  of  hierarchical  domains  or 
protection  rings  [13J .  O'Connell  and  Ricnardson  [lj  defined 
three  domains  in  the  family  of  secure  operating  systems:  the 
user,  the  supervisor,  and  the  kernel.  Only  two  domains  are 
actually  necessary  in  the  SASS  design  since  it  does  not 
provide  extended  user  applications.  The  Kernel  resides  in 
the  inner  or  most  privileged  domain  and  has  access  to  all 
segments  in  an  address  space.  System  wide  data  bases  are 
also  maintained  within  the  Kernel  domain  to  insure  their 
accessibility  is  only  through  the  Kernel.  Tne  Supervisor 
exists  in  the  outer  or  least  privileged  domain  where  its 
access  to  data  or  segments  within  an  address  space  is 
restricted . 
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While  protection  domains  may  be  created  through 
either  hardware  or  software  mechanisms,  a  hardware 
implementation  provides  much  greater  efficiency.  Current 
microprocessor  technology  only  provides  for  the 
implementation  of  two  domains.  This  two  domain  restriction 
does  not  support  O'Connell  and  Richardson's  complete  family 
design,  hut  it  is  sufficient  to  allow  hardware 
implementation  of  the  ring  structure  required  by  the  SASS 
subset. 

5.   A05tra.QUQn, 

Dijfcstra  [14]  has  shown  tnat  tne  notion  of 
abstraction  can  be  used  to  reduce  the  complexity  of  a 
problem  by  applying  a  general  solution  to  a  number  of 
specific  cases.  A  structure  of  increasing  levels  of 
abstraction  provides  a  powerful  tool  for  tne  design  of 
complex  systems  and  generally  leads  to  a  better  design  with 
greater  clarity  and  fewer  errors. 

Each  level  of  abstraction  creates  a  virtual 
hierarchical  machine  [8J  which  provides  a  set  of  "extended 
instructions"  to  tne  system.  A  virtual  machine  cannot  maice 
calls  to  another  virtual  machine  at  a  higher  level  of 
abstraction  and  in  fact  is  unaware  of  its  existence.  This 
implies  that  a  level  of  abstraction  is  independent  of  any 
higher  levels.  This  independence  provides  for  a  loop-free 
design.  Additionally,  a  higher  level  may  only  ma&e  use  of 
the  resources  of  a  lower  level  by  applying  the  extended 
instruction   set    of   the   lower   level   virtual  machine. 
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Therefore,  once  a  level  of  abstraction  is  created,  any 
nigher  level  is  only  interested  in  tne  extended  instruction 
set  it  provides  and  is  not  concerned  witn  tne  details  of  its 
implementation.  In  SASS,  once  a  level  of  abstraction  is 
created  for  the  physical  resources  of  the  system,  these 
resources  become  "virtuaiized"  making  the  higher  levels  of 
the  design  independent  of  the  physical  configuration  of  the 
system. 

C.   THESIS  STRUCTURE 

This  thesis  describes  the  implementation  of  the  process 
management  functions  for  the  SASS.  The  design  base  for  this 
implementation  evolved  from  the  secure  family  of  operating 
systems  designed  by  O'Conneli  and  Richardson  [lj  .  The 
programming  language  utilized  in  this  implementation  was 
PLZ/ASM  assembly  code  [20J  . 

Chapter  I  provided  an  introduction  to  the  Secure 
Archival  Storage  System  and  a  discussion  of  the  basic 
concepts  which  underlie  a  secure  operating  system 
envi  ronment . 

Chapter  II  will  provide  a  discussion  of  tne  SASS  design. 
An  overview  of  the  entire  SASS  system  is  presented  alone 
with  more  detailed  description  of  the  modules  comprising 
SASS  and  their  associated  databases. 

Chapter  III  discusses  the  issues  bearing  on  this 
implementation  and  the  refinements  made  to  previous  SASS 
related  worK.  A  discussion  concerning  the  initialization  of 
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the  databases  utilized  by  tne  current  SASS  demonstration  is 
also  presented. 

Chapter  IV  presents  tne  implementation  of  process 
management  (viz.,  tne  Traffic  Controller,  Event  Manager, 
Distributed  Memory  Manager,  and  Gate  Keeper  stub  modules).  A 
description  of  design  and  implementation  criteria,  and 
decisions  made  during  implementation  are  also  discussed  in 
this  chapter. 

Chapter  V  provides  the  conclusions  reached,  the  status 
of  the  researcn,  and  recommendations  relative  to  the 
continuation  and  extension  of  this  woric. 

The  appendices  include  the  PLZ/ASM  code  for  tne  modules 
implemented  and  refined.  The  complete  program  listings  for 
the  Secure  Archival  Storage  System  may  be  obtained  from  a 
report  prepared  by  Schell  and  Cox  [22] . 
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II.  SECURE  ARCHIVAL  STORAGE  SYSTEM  DESIGN 

This  chapter  provides  an  overview  of  the  SASS  in  its 
current  design  state.  The  intent  of  tnis  summary  is 
threefold.  First,  it  is  intended  to  provide  an  overall 
understanding  of  the  SASS  itself.  Secondly,  it  will  provide 
an  interrelationship  between  the  wori  done  in  this  thesis 
and  previous  wort  performed  on  SASS.  Lastly,  it  provides  a 
current  base  upon  which  further  SASS  development  can  occur. 

A.   BASIC  SASS  OVERVIEW 

The  purpose  of  the  Secure  Archival  Storage  System  is  to 
provide  a  secure  "data  warehouse"  or  information  pool  whicn 
can  be  accessed  and  shared  by  a  variable  set  of  host 
computer  systems  possessing  differing  security 
classifications.  The  primary  goals  of  the  SASS  design  are  to 
provide  information  security  and  controlled  sharing  of  data 
among  system  users. 

Figure  1  provides  an  example  of  a  possible  SASS  usage. 
The  system  is  used  exclusively  for  managing  an  archival 
storage  system  and  does  not  provide  any  programming  services 
to  its  users.  Thus  the  users  of  the  SASS  may  only  create, 
store,  retrieve,  or  modify  files  within  the  SASS.  The  host 
computers  are  hardwired  to  the  system  via  the  I/O  ports  of 
the  Z8001   with   each   connection   having   a  fixed  security 
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Figure   1.      SASS    System 
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classification.  Each  Host  must  nave  a  separate  connection 
for  eacn  security  level  it  wishes  to  worfc  on  (It  is 
important  to  note  that  Figure  1  only  represents  the  logical 
interfacing  of  tne  system.  Specifically,  tne  actual 
connection  with  tne  nost  system  must  be  interfaced  with  the 
Kernel  as  tne  I/O  instructions  for  tne  port  are  privileged). 
In  our  example.  Host  #1  can  create  and  modify  only  Top 
Secret  files,  but  it  can  read  files  which  are  Top  Secret, 
Secret,  Confidential,  or  Unclassified.  Likewise,  Host  #2  can 
create  or  modify  secret  files,  using  its  secret  connection 
or  confidential  files,  using  its  confidential  connection. 
Host  #2  cannot  create  or  modify  Top  Secret  or  Unclassified 
files. 

In  order  to  provide  information  security  and  controlled 
sharing  of  files,  the  SASS  operates  in  two  domains:  (l)  the 
Supervisor  domain  and  (2)  tne  Kernel  domain.  The  SASS 
achieves  this  desired  environment  through  a  districted 
operating,  system  design  wnicn  consists  of  two  primary 
modules:  the  Supervisor  and  the  Security  Kernel.  Each  host 
system  connected  to  the  SASS  nas  associated  witn  it  two 
processes  within  the  SASS  which  perform  the  data  transfer 
and  file  management  on  benalf  of  tnat  host.  Tne  host 
computer  communicates  directly  with  its  own  I/O  process  and 
File  Manager  process  within  the  SASS. 

We  can  use  our  notion  of  abstraction  to  present  a  system 
overview  of  the  SASS.  The   SASS   consists   of   four   primary 
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levels  of  abstraction: 

Level  3-The  Host  Computer  Systems 

Level  2-The  Supervisor 

Level  l-The  Security  Kernel 

Level  0-The  SASS  Hardware 
A  pictorial  representation  of  tnis  abstract  system  overview 
is  presented  in  Figure  2.  This  representation  is  limited  to 
a  dual  nost  system  for  clarity  and  space  restrictions.  Note 
that  the  Gate  Keeper  module  is  in  actuality  the  logical 
boundary  between  levels  one  and  two  and  as  such  %ill  be 
described  separately. 

Level  3,  the  host  computer  systems,  of  SASS  has   already 

been  addressed.  It  should  be  noted  that  the  SASS  design 
mates  no  assumptions  about  the  host  computer  systems. 
Therefore  each  host  may  be  of  a  different  type  or  size 
(i.e.-  micro,  mini,  or  maxi-computer  system).  Furthermore,' 
the  necessary  physical  security  of  tne  host  systems  and 
their  respective  data  lints  with  the  SASS  is  assumed. 

B.   SUPERVISOR 

Level  2  of  the  SASS  system  is  composed  of  the  Supervisor 
domain.  As  already  stated,  the  SASS  consists  of  two  domains. 
The  actual  implementation  of  these  domains  was  greatly 
simplified  since  the  78001  microprocessor  provides  two  modes 
of  execution.  The  system  mode,  *ith  which  the  Kernel  was 
implemented,  provides  access  to  all  macnine  instructions  and 
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all  segments  within  the  system.  The  normal  mode,  with  which 
tne  Supervisor  was  implemented,  only  provides  access  to  a 
limited  subset  of  machine  instructions  and  segments  within 
tne  system.  Tnerefore,  tne  Supervisor  operates  in  an  outer 
or  less  privileged  domain  than  the  Kernel. 

The  purpose  of  tne  Supervisor  is  to  manage  tne  data  link 
between  the  host  computer  systems  and  the  SASS  by  means  of 
Input/Output  control,  and  to  create  and  manage  tne  file 
hierarchy  of  each  host  within  the  SASS.  These  functions  are 
accomplished  via  an  Input/Output  (I/O)  process  and  a  File 
Manager  (FM)  process  within  the  Supervisor.  A  separate  FM 
and  I/O  process  are  created  and  dedicated  to  eacn  nost  at 
the  time  of  system  initialization. 

1.   File  Manager  Process 

The  FM  process  directs  the  interaction  between  the 
host  computer  systems  and  the  SASS.  It  interprets  all 
commands  received  from  the  Host  computer  and  performs  the 
necessary  action  upon  them  through  appropriate  calls  to  the 
Kernel.  The  primary  functions  of  tne  FM  process  are  tne 
management  of  the  Host's  virtual  file  system  and  the 
enforcement  of  the  discretionary  security  policy. 

The  virtual  file  system  of  the  Host  is  viewed  as  a 
hierarchy  of  files  wnich  are  implemented  in  a  tree 
structure.  The  five  basic  actions  which  may  he  initiated 
upon  a  file  at  this  level  are:  1)  to  create  a  file,  2)  to 
delete  a  file,  3)  to  read  a  file,  4)  to  store  a  file,  and  5) 
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to  modify  a  file.  The  FM  process  utilizes  a  FM  Known  Segment 
Table  (FM_KST)  as  tne  primary  database  to  aid  in  tnis 
management . 

Tfie  FM  process  maintains  an  Access  Control  List 
(ACL)  through  which  it  enforces  the  discretionary  security 
in  SASS.  The  FM  process  initializes  an  ACL  for  every  file  in 
its  Host's  file  system.  The  ACL  is  merely  a  list  of  all 
users  tnat  are  autnorized  to  access  tnat  file.  Tne  ACL  is 
checked  upon  every  attempt  to  access  a  file  to  determine  its 
autnorization.  The  user  (nost  computer)  directs  tne  FM 
process  as  to  what  entries  or  deletions  should  be  made  in 
the  ACL,  and  as  sucn,  specifies  wno  ne  wlsnes  to  nave  access 
to  his  file.  As  noted  earlier,  discretionary  security  is  a 
refinement  to  the  Non-Discretionary  Security  Policy  and 
therefore  can  only  be  utilized  to  add  furtner  access 
restrictions  to  those  provided  by  the  Non-Discretionary 
Security."  This  prevents  a  user  from  granting  access  to  a 
file  to  someone  who  otherwise  would  not  he  authorized 
access. 

2.   Input/Output  Process 

The  I/O  process  is  responsible  for  managing  the 
input  and  output  of  all  data  between  tne  nost  computer 
systems  and  the  SASS.  The  I/O  process  is  subservient  to  the 
FM  process  and  receives  all  of  its  commands  from  it.  Data  is 
transferred  between  the  SASS  and  Host  Computer  systems  in 
fixed  size  "packets".  These  packets  are  broken  up  into  three 
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basic  types:  1)  a  synchronization  packet,  2)  a  coirmand 
pacKet,  and  3)  a  data  pacKet.  In  order  to  insure  reliable 
transmission   and   receipt   of  packets   between   the   Host 

computer  and  the  SASS,  there  must  exist  a  protocol  between 
them.  Paris  [2]  provides  a  more  detailed  description  of 
these  packets,  and  a  possible  multi-pacKet  protocol. 

C.   GATE  KEEPER 

The  primary  objective  of  the  gate  Keeper  is  to  isolate 
the  Kernel  and  maKe  it  tamperproof.  This  f?oal  is 
accomplished  by  reason  of  a  software  ring  crossing  mecnanism 
provided  by  the  ^ate  Keeper.  In  terms  of  SASS,  this  notion 
of  "ring-crossing"  is  merely  the  transition  from  tne 
Supervisor  domain  to  the  Kernel  domain.  As  noted  earlier, 
the  gate  Keeper  establishes  the  logical  boundary  between  the 
Supervisor  and  the  Kernel,  and  as  a  matter  of  course,  it 
provides  a  single  software  entry  point  (enforcea  by 
hardware)  into  the  Kernel.  Therefore,  any  call  to  the  Kernel 
must  first  pass  through  the  gate  Keeper. 

The  ffate  Keeper  acts  as  a  trap  handler.  Once  it  is 
invoKed  by  a  user  (Supervisor)  process,  the  hardware  preempt 
interrupts  are  masKed,  and  the  user  process'  registers  and 
stacK  pointer  are  saved  (within  the  Kernel  domain).  It  then 
taKes  the  argument  list  provided  by  the  caller  and  validates 
these  passed  parameters  to  insure  tneir  correctness.  To  aid 
in   the  validation  of   these   parameters,   the  sate   Keeper 
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utilizes  the  Parameter  Table  as  a  database.  The  Parameter 
table  contains  all  of  tne  permitted  functions  provided  by 
tne  Kernel.  These  relate  directly  to  the  extended 
instruction  set  (viz..  Supervisor  calls)  provided  by  the 
Kernel  (these  extended  instructions  will  be  described  in  the 
next  section).  If  an  invalid  call  is  encountered  by  the  gate 
Keeper,  an  error  code  is  returned,  and  the  Kernel  is  not 
invoiced.  If  a  valid  call  is  encountered  by  tne  gate  Keeper, 
the  arguments  and  control  are  passed  to  the  appropriate 
Kernel  module. 

Once  the  Kernel  has  completed  its  action  on  tne  user 
request,  it  passes  the  necessary  parameters  and  control  bacK 
to  the  gate  Keeper.  At  this  point,  the  gate  Keeper 
determines  if  any  software  virtual  preempt  interrupts  nave 
occurred.  If  they  nave,  then  the  virtual  preempt  handler  is 
invoKed  vice  the  Kernel  bein?  exited  (virtual  interrupt 
structure  is  discussed  in  chapter  III).  Correspondingly,  if 
a  software  virtual  preempt  has  not  occurred,  then  the  return 
arguments  are  passed  to  tne  user  process.  The  user  process' 
registers  and  stacK  pointer  (viz.,  its  execution  point)  are 
restored  and  control  returned  to  tne  Supervisor  domain.  A 
detailed  description  of  the  Gate  Keeper  interface  and 
implementation  is  provided  in  chapter  IV. 
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D.  DISTRIBUTED  KERNEL 

Level  1  of  our  abstract  view  of  SASS  consists  of  two 
components:  the  distributed  Kernel  and  tne  non-distributed 
Kernel.  These  two  elements  comprise  tne  Security  Kernel  of 
the  SASS.  The  Security  Kernel  has  two  primary  objectives:  1) 
the  management  of  the  system's  nardware  resources,  and  2^ 
the  enforcement  of  the  non-discretionary  security  policy.  It 
executes  in  the  most  privileged  domain  (viz..  the  system 
mode  of  the  Z8001)  and  nas  access  to  all  machine 
instructions.  Tne  following  section  will  provide  a  crief 
description  of  the  distributed  Kernel,  its  components,  and 
the  extended  instruction  set  it  provides.  A  discussion  of 
the  non-distributed  Kernel  will  be  giver  in  the  next 
section. 

The  distributed  Kernel  consists  of  those  Kernel  modules 
whose  segments  are  contained  (distributed)  in  the  address 
space  of  every  user  (Supervisor)  process.  Thus,  in  effect, 
the  distributed  Kernel  is  shared  by  all  user  processes  in 
the  SASS.  Tne  distributed  Kernel  is  composed  of  the  Segment 
Manager,  the  Event  Manager,  the  Non-Discretionary  Security 
Module,  tne  Traffic  Controller,  tne  Inner  Traffic 
Controller,  and  the  Distributed  Memory  Manager  Module.  The 
Segment  Manager  and  the  Event  Manager  are  the  only  "user 
visible"  modules  in  the  distributed  Kernel.  In  other  words, 
the  set  of  extended  instructions  available  to  user  processes 
invoice  either  the  Segment  Manager  or  the  Event  Manager. 

• 
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1.   Segment  Manager 

The  objective  of  the  Segment  Manager  is  the 
management  of  a  process'  segmented  virtual  storage.  The 
Segment  Manager  is  invoiced  by  calls  from  the  Supervisor 
domain  via  the  gate  keeper.  Calls  to  tne  Segment  Manager  are 
made  by  means  of  six  extended  instructions  provided  by  the 
segment  manager.  These  extended  instructions  (viz.,  entry 
points)  are:  l)  CREATE_SEGMENT ,  2)  DELETE_SEGMENT ,  3) 
MAKE_KNOWN,  4)  TERMINATE,  5)  SM_SWAP_IN,  and  6)  SM_SWAF_OUT. 
The  extended  instructions  CREATE_SEGMENT  and  DELETE_SEGMENT 
add  and  remove  segments  from  the  SASS.  MAKE_KNOWN  and 
TERMINATE  add  and  remove  segments  from  the  address  space  of 
a  process.  Finally,  SM_SWAP_IN  and  SM_SWAP_OUT  move  segments 
from  secondary  storage  to  main  storage  and  vice  versa. 

The  primary  database  utilized  by  the  Segment  Manager 
is  the  Known  Segment  Table  (KST)  .  A  representation  of  the 
structure  of  the  KST  is  provided  in  figure  3.  The  KST  is  a 
process  local  database  that  contains  an  entry  for  every 
segment  in  the  address  space  of  that  process.  The  KST  is 
indexed  by  segment  number  with  each,  record  of  tne  KST 
containing  descriptive  information  for  a  particular  segment. 
The  KST  provides  a  mapping  mechanism  by  which  tne  segment 
number  of  a  particular  segment  can  be  converted  into  a 
uniaue  nandle  for  use  by  tne  Memory  Manager.  The  Memory 
Manager  will  be  discussed  in  the  next  section. 
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Figure  3.   Known  Segment  Table  (KST) 
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2.   Event  Manager 

The  purpose  of  the  Event  Manager  is  the  management 
of  event  data  which  is  associated  with  interprocess 
communications  within  the  SASS.  Tnis  event  data  is 
implemented  by  means  of  eventcounts  (a  synchronization 
primitive  discussed  by  Reed  [15J ) .  Tne  Event  Manager  is 
invoked,  via  the  Gate  Keeper,  by  user  processes  residing  in 
the  Supervisor  domain.  Tnere  are  two  eventcounts  associated 
with  every  segment  existing  in  the  Supervisor  domain.  These 
eventcounts  (viz.,  Instance  l  and  Instance  2)  are  maintained 
in  a  database  residing  in  the  Memory  Manager.  The  Event 
Manager  provides  its  management  functions  througn  its 
extended  instruction  set  READ,  TICKET,  ADVANCE,  and  AWAIT, 
and  in  conjunction  with  the  extended  instructions  TC_ADVANCE 
and  TC_AWAIT  provided  by  the  Traffic  Controller  (to  be 
discussed  next).  These  extended  instructions  are  based  on 
the  mechanism  of  eventcounts  and  sequencers  [15 J .  The  Event 
Manager  verifies  the  access  permission  of  every  interprocess 
communication  request  through  the  Non-Discretionary  Security 
Module.  The  extended  instruction  READ  provides  tne  current 
value  of  the  eventcount  requested  by  the  caller.  TICKET 
provides  a  complete  time  ordering  of  possibly  concurrent 
events  through  the  mechanism  of  sequencers.  The  Event 
Manager  will  be  discussed  in  more  detail  in  chapter  IV. 
3.   Non-Discretionary  Security  Module 

The  purpose  of  the  Non-Discretionary  Security  Module 
(NDS)  is  the  enforcement  of  the  non-discretionary  security 
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policy  of  the  SASS.  Wnile  the  current  implementation  of  SASS 
represents  the  Department  of  Defense  security  policy,  any 
security  policy  wnicn  may  be  represented  tnrougn  a  lattice 
structure  [12]  may  also  be  implemented.  The  NDS  is  invoiced 
via  its  extended  instruction  set:  CLASS_EQ  and  CLASS_GE.  Tne 
NDS  is  passed  two  classifications  which  it  compares  and  then 
analyzes  their  relationship.  CLASS_E0  will  return  a  true 
value  to  the  calling  procedure  only  if  the  two 
classifications  passed  were  equal.  The  CLASS_GE  instruction 
will  return  true  if  a  given  classification  is  analyzed  to  be 
either  greater  than  or  equal  to  another  given 
classification.  The  NDS  does  not  utilize  a  data  base  as  it 
worts  only  with  tne  parameters  it  is  passed. 
4.   Traffic  Controller 

The  tasir  of  processor  scheduling  is  performed  by  the 
traffic  controller.  Saltzer  [16 J  defines  traffic  controller 
as  tne  processor  multiplexing  and  control  communication 
section  of  an  operating  system.  The  current  SASS  design 
utilizes  Reed's  [9J  notion  of  a  two  level  traffic 
controller,  consisting  of:  l)  a  Traffic  Controller  (TC)  and 
2)  an  Inner  Traffic  Controller  (ITC). 

The  primary  function  of  the  Traffic  Controller  is 
the  scheduling  (binding)  of  user  processes  onto  virtual 
processors.  A  virtual  processor  (V?)  is  an  abstract  data 
structure  that  simulates  a  physical  processor  through  the 
preservation  of  an  executing  process'  attributes  (viz.,   tne 
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execution  point  and  address  space).  Multiple  VP's  may  exist 
for  every  pnysical  processor  in  the  system.  Two  VP's  are 
permanently  bound  to  Kernel  processes  (viz.,  Memory  Manager 
and  Idle)  and  as  sucft  are  not  in  contention  tor  process 
scheduling.  Tnese  processes  and  tneir  corresponding  virtual 
processors  are  invisible  to  the  TC.  The  remaining  virtual 
processors  are  either  idle  or  are  temporarily  bound  to  user 
processes  as  scheduled  by  the  TC .  The  database  utilized  by 
the  TC  in  process  scheduling  is  the  Active  Process  Table 
(APT).  Figure  4  provides  the  structure  of  the  APT. 

The  APT  is  a  system-wide  Kernel  database  containing 
an  entry  for  every  user  process  in  the  system.  Since  the 
current  SASS  design  does  not  provide  for  dynamic  process 
creation/deletion,  a  user  process  is  active  for  the  life  of 
the  system.  Therefore,  tne  size  of  the  APT  is  fixed  at  the 
time  of  system  veneration.  The  APT  is  logically  composed  of 
three  parts:  1)  an  APT  neader,  2)  the  main  body  of  tne  APT, 
and  3)  a  VP  table.  The  APT  header  includes:  1)  a  Loci  to 
provide  for  a  mutual  exclusion  mecnanism,  2)  a  Running  List 
indexed  by  VP  ID  to  identify  the  current  process  running  on 
each  VP,  3)  a  Ready  List,  which  points  to  the  linked  list  of 
processes  which  are  ready  for  scheduling,  and  4)  a  blocked 
List,  which  points  to  the  linked  list  of  processes  wnicn  are 
in  the  blocked  state  awaiting  the  occurrence  of  some  event. 

A  design  decision  was  made  to  incorporate  a  single 
list  of  blocked  processes  instead  of   the   more   traditional 
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Figure  4.   Active  Process  Table  (APT) 
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notion  of  separate  lists  per  eventcount  because  of  its 
simplicity  and  its  ease  of  implementation.  Tnis  decision 
does  not  appreciably  affect  system  performance  or  efficiency 
as  the  "blocked"  list  will  never  be  very  long.  The  VP  table 
is  indexed  by  logical  CPU  number  and  specifies  tne  number  of 
VP's  associated  with  the  logical  CPU  and  its  first  VP  in  the 
Running  List.  The  logical  CPU  number,  obtained  during  system 
initialization,  provides  a  simple  means  of  uniquely 
identifying  each  pnysical  CPU  in  the  system.  The  main  body 
of  the  APT  contains  the  user  process  data  required  for  its 
efficient  control  and  scheduling.  NEXT_AP  provides  the 
linked  list  threading  mechanism  for  process  entries.  The  DBR 
entry  is  a  handle  identifying  the  process'  Descriptor 
Segment  which  is  employed  in  process  switching  and  memory 
management.  The  ACCESS_CLASS  entry  provides  every  process 
with  a  security  label  that  is  utilized  by  the  Event  Manager 
and  the  Segment  Manager  in  the  enforcement  of  the 
Non-Discretionary  Security  Policy.  The  PRIORITY  and  STATE 
entries  are  the  primary  data  used  by  the  Traffic  Controller 
to  effect  process  scheduling.  AFFINITY  identifies  the 
logical  CPU  which  is  associated  with  tne  process.  VP  IE  is 
utilized  to  identify  the  virtual  processor  tnat  is  currently 
bound  to  the  process.  Finally,  the  EVENTCOUNT  entries  are 
utilized  by  the  TC  to  manage  processes  which  are  blocked  and 
awaiting  the  occurrence  of  some  event.  EANELE  identifies  the 
segment  associated  with  the  event,   INSTANCE   specifies   the 
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event,  and  COUNT  determines  which  occurrence  of  the  event  is 
needed. 

The  Traffic  Controller  determines  the  scheduling 
order  by  process  priority.  Every  process  is  assigned  a 
priority  at  the  time  of  its  creation.  Once  scheduled,  a 
process  will  run  on  its  VP  until  it  either  blocks  itself  or 
it  is  preempted  by  a  higher  priority  process.  To  insure  that 
the  TC  will  always  have  a  process  available  for  scheduling, 
there  logically  exists  an  "idle"  process  for  every  VP 
visible  to  the  TC.  These  "idle"  processes  exist  at  the 
lowest  process  priority  and,  consequently,  are  scheduled 
only  if  there  exists  no  useful  worK  to  be  performed. 

The  Traffic  Controller  is  invoked  by  the  occurrence 
of  a  virtual  preempt  interrupt  or  through  its  extended 
instruction  set:  ADVANCE,  AWAIT,  PROCESS_CLASS ,  and 
GET_DBP._NUMBER.  ADVANCE  and  AWAIT  are  used  to  implement  the 
IPC  mechanism  envoked  by  the  Supervisor.  PROCESS_CLASS  and 
GET_DBR_NUMBER  are  called  by  the  Segment  ^anas-er  to 
ascertain  the  security  label  and  DBH  handle,  respectively, 
of  a  named  process.  A  more  detailed  discussion  of  the  TC  is 
provided  in  chapters  III  and  IV. 
5.   Inner  Traffic  Controller 

The  Inner  Traffic  Controller  is  the  second  part  of 
our   two-level   traffic   controller.   Basically,    the    ITC 

performs   two   functions.   It  multiplexes  virtual  processors 
onto  the  actual  physical  processors,   and   it   provides   the 
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primitives  for  wnicn  inter-VP  communication  witnin  tne 
Kernel  is  implemented.  A  design  cnoice  was  made  to  provide 
eacn  pnysical  processor  in  tne  system  vitn  a  small  fixed  set 
of  virtual  processors.  Two  of  tnese  VP's  are  permanently 
bound  to  tne  Kernel  processes.  Tne  Memory  Manager  is  tound 
to  the  highest  priority  VP.  Conversely,  the  Idle  Process  is 
bound  to  tne  lowest  priority  VP  and,  as  a  result,  will  only 
be  scheduled  if  there  exists  no  useful  work  for  the  CPU  to 
perform.  Tne  primary  database  utilized  by  tne  ITC  is  the 
Virtual  Processor  Table  (VPT).  Figure  5  illustrates  the  VPT. 
The  VPT  is  a  system  wide  Kernel  database  containing 
entries  for  every  CPU  in  the  system.  The  VPT  is  logically 
composed  of  four  parts:  1)  a  neader,  2)  a  VP  data  table,  3) 
a  message  table,  and  4)  an  external  VP  list.  The  header 
includes  a  LOCK  (spin  lode)  that  provides  a  mutual  exclusion 
mechanism  for  table  access,  a  RUNNING  LIST  (indexed  by 
logical  CPU  #)  that  identifies  the  V?  currently  running  on 
the  corresponding  pnysical  CPU,  a  READ!  LIST  (indexed  by 
logical  CPU  #)  which  points  to  tne  linked  list  of  VP's  which 
are  in  the  "ready"  state  and  awaiting  scheduling  on  that 
CPU,  and  a  FREE  LIST  wnicn  points  to  the  linked  list  of 
unused  entries  in  the  message  table.  Tne  VP  data  table 
contains  tne  descriptive  data  required  by  tne  ITC  to 
effectively  manage  the  virtual  processors.  The  DBR  entry 
points  within  tne  MMU  Image  to  the  descriptor  segment  for 
the  process  currently  running  on   the   VP.   PRI   (Priority), 
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STATE,  IDLE_ELAG,  and  PREEMPT  are  tne  primary  data  used  by 
the  ITC  for  VP  scheduling.  PREEMPT  indicates  whether  cr  not 
a  virtual  preempt  is  pending  for  the  VP.  The  IDLE_FLAG  is 
set  whenever  the  TC  has  bound  an  "idle"  process  to  the  VP. 
Normally,  a  VP  with  the  IDLE_FLAG  set  will  not  be  scneduled 
"by  the  ITC  as  it  has  no  useful  wort  to  perform.  In  fact, 
sucn  a  VP  will  only  be  scneduled  if  tne  PREEMPT  flag  is  set. 
This  scheduling  will  allow  the  VP  to  be  given  (bound)  to 
anotner  process.  PHYSICAL  PROCESSOR  contains  an  entry  from 
the  Processor  Data  Segment  (PRDS)  that  identifies  the 
pnysical  processor  tnat  tne  VP  is  executing  on.  EJT_V?_ID  is 
the  identifier  by  which  the  VP  is  Known  by  the  Traffic 
Controller.  A  design  choice  was  made  to  nave  tne  EXT_VP_ID 
equate  to  an  offset  into  the  External  VP  List.  The  External 
V?  List  specifies  tne  actual  VP  ID  (viz..  VPT  entry  number) 
for  each  external  vp  identifier.  This  precluded  the 
necessity  for  run  time  calculation  of  offsets  for  the 
EXT_VP_ID.  NEXT  RSADT  VP  provides  the  threading  mechanism 
for  tne  "Ready"  linked  list,  and  MSG  LIST  points  to  tne 
first  entry  in  the  Message  Table  containing  a  message  for 
that  VP.  The  Message  Table  provides  storage  for  the  messages 
generated  in  the  course  cf  Inter-Virtual  Processor 
communications.  MSG  contains  tne  actual  communication  being 
passed,  while  SENDER  identifies  the  VP  which  initiated  the 
communication.  NEXT_MSG  provides  a  tnreading  mecnanism  for 
multiple  messages  pending  for  a  single  VP. 
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The  ITC  is  invoiced  by  means  of  its  extended 
instruction  set:  WAIT,  SIGNAL,  SWAP_VDBR,  IDLE,  SET_PPEEMPT, 
and  RUNNING_VP.  WAIT  and  SIGNAL  are  the  primitives  employed 
in  implementing  the  Inter-VP  communication.  SWAP_VDBR,  IDLE, 
SET_PRE£MPT,  and  RUNNING_VP  are  all  invoked  by  tne  Traffic 
Controller.  SWAP_VDBR  provides  the  means  by  whicn  a  user 
process  is  temporarily  bound  to  a  virtual  processor.  IDLE 
binds  the  "idle"  process  to  a  VP  (tne  implication  of  this 
instruction  will  be  discussed  later).  SET_PREEMPT  provides 
the  means  of  indicating  that  a  virtual  preempt  interrupt  is 
pending  on  a  VP  (specified  hy  the  TO  by  setting  the  PREEMPT 
flag  for  that  VP  in  the  VPT.  RUNNINGJTP  provides  tne  TC  with 
the  external  VP  ID  of  the  virtual  processor  currently 
running  on  the  physical  processor. 
6.   Distributed  Memory  Manager 

The  Distributed  Memory  Manager  provides  an  interface 
structure  between  the  Segment  Manager  and  the  Memory  Manager 
Process.  Tnis  interfacing  is  necessitated  by  the  fact  tnat 
the  Memory  Manager  Process  does  not  reside  in  the 
Distributed  Kernel  and  consequently  is  not  included  in  the 
user  process'  address  space.  The  primary  functions  performed 
in  tnis  module  are  tne  establishment  of  Inter-VP 
Communication  between  the  VP  bound  to  its  user  process  and 
tne  VP  permanently  bound  to  the  Memory  Manager  Process,  tne 
manipulation  of  event  data,  and  the  dynamic  allocation  of 
available  memory.   Tne  Distributed  Memory  Manager  Module  is 
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invoked  by  the  Segment  Manager  tnrough  its  extended 
instruction  set:  MM_CREATE_ENTRY,  MM_EELETE_ENTRT , 
MM_ACTIVATE,  MM_DEACTIVATE ,  MM_SWA?_INf  and  MM_SWAP_OUT. 
Tnese  extended  instructions  are  utilized  on  a  one  to  one 
basis  by  the  extended  instruction  set  of  the  Segment  Manager 
(e.g.,  SM_SWAP_IN  utilizes  (calls)  MM_SWAP_IN).  Wells  (6J 
provides  a  more  detailed  description  of  this  portion  of  the 
Distributed  Memory  Manager  and  the  extended  instruction  set 
associated  with  it. 

The  Distributed  Memory  Manager  is  also  invoked 
tnrough  its  remaining  extended  instructions: 
MM_READ_EVENTCOUNT,  MM_TICKET,  MM_ADVANCE,  and  MM_ALLOCATE. 
These  Distributed  Memory  Manager  functions  will  be  discussed 
in  detail  in  chapter  IV. 

E.   NON-DISTRIBUTEE  KERNEL 

The  Non-Distributed  Kernel  is  the  second  element 
residing  in  Level  l  of  our  abstract  system  view  of  the  SASS. 
The  sole  component  of  the  Non-Distri outed  Kernel  is  the 
Memory  Manager  Process. 

1 .   Memory  Manager  Process 

The  primary  purpose  of  the  Memory  Manager  Process  is 
the  management  of  all  memory  resources  witbin  the  SASS. 
These  include  tne  local  and  global  main  memories,  as  well  as 
the  hard-disk  based  secondary  storage.  A  dedicated  Memory 
Manager  Process  exists  for  every  CPU  in  tne  system.  Each  CPU 
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possesses  a  local  memory  where  process  local  segments  and 
snared,  non-writeable  segments  are  stored.  There  is  also  a 
Global  memory,  to  which  every  CPU  has  access,  where  the 
shared,  writeable  segments  are  stored.  It  is  necessary  to 
store  these  shared,  writeable  segments  in  the  global  memory 
to  ensure  that  a  current  copy  exists  for  every  access. 

The  Memory  Manager  Process  is  tasked  by  other 
processes  within  the  Kernel  domain  (via  Signal  and  Wait)  to 
perform  memory  management  functions.  These  basic  functions 
include  the  allocation/deallocation  of  local  and  glotal 
memory  and  of  secondary  storage,  and  the  transfer  of 
segments  between  tne  local  and  global  memory  and  between 
secondary  storage  and  the  main  memories.  The  extended 
instruction  set  provided  by  tne  Memory  Manager  Process 
includes:  CHEATE_ENTRY,  DELETE_ENTR7,  ACTIVATE,  DEACTIVATE, 
SWAP_IN,  and  SVAP_OUT.  These  instructions  correspond  one  to 
one  with  those  of  the  Distributed  Memory  Manager  Module.  The 
system  wide  data  bases  utilized  by  all  Memory  Manager 
Processes  are  tne  Global  Active  Segment  Table  (G_AST),  the 
Alias  Table,  the  Distr  Bit  Map,  and  the  Global  Memory  Bit 
Map.  The  processor  local  databases  used  by  each  Memory 
Manager  Process  are  the  Local  Active  Segment  Table  (L_AST), 
and  the  Local  Memory  Bit  Map.  Gary  and  Moore  l4j  provide  a 
detailed  description  of  tne  Memory  Manager,  its  extended 
instruction  set,  and  its  databases. 
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A  summary  of  the  extended  instruction  set  created  by 
the  components  of  tne  Security  Kernel  is  provided  by  Figure 
6.  One  mignt  question  tne  prudence  of  omitting 
FHYS_PFEEMPT_FANDL£R  and  VIRT_PREEMPT_HAND1SR  (viz.,  tne 
nandier  routines  for  pnysical  and  virtual  interrupts^  from 
the  extended  instruction  set  as  both  of  tnese  interrupts  may 
■fee  raised  (viz.,  initiated)  from  within  tne  Kernel.  A 
decision  was  made  to  not  classify  these  handlers  as 
"extended  instructions"  since  tney  are  only  executed  as  tne 
result  of  a  physical  or  virtual  interrupt  and  as  such  cannot 
be  directly  invoiced  (viz.t  "called")  by  any  module  in  the 
system.  A  summary  of  the  databases  utilized  by  Kernel 
modules  is  presented  in  Figure  7. 

F.   SYSTEM  HARDWARE 

Level  0  of  the  SASS  consists  of  the  system  hardware. 
This  nardware  includes:  1)  tne  CPU,  2)  the  local  memory,  3) 
the  global  memory,  4)  the  secondary  storage  (viz.  nard 
disfc),  and  5)  tne  I/O  ports  connecting  tne  Host  computer 
systems  to  the  SASS.  Since  the  SASS  design  allows  for  a 
multiprocessor  environment,  tnere  may  exist  multiple  CPU's 
and  local  memories.  The  target  machine  selected  for  the 
initial  implementation  of  tne  system  is  tne  Zilog  Z8001 
microprocessor  [17] .  The  Z8001  is  a  general  purpose  lb-bit, 
register  oriented  macnine  tnat  nas  sixteen  16-bit  general 
purpose   registers.   It   can  directly  address   8M  bytes  of 
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memory,  extensible  to  48M  bytes.  Tne  Z8001  arcnitecture 
supports  memory  segmentation  and  two-domain  operations.  The 
memory  segmentation  capability  is  provided  externally  by  tne 
Zilog  Z8010  Memory  Management  Unit  (MMU).  Tne  Z8010  MMU  [16J 
provides  management  of  tne  Z8001  addressable  memory,  dynamic 
segment  relocation,  and  memory  protection.  Memory  segments 
are  variable  in  size  from  256  bytes  to  64K  bytes  and  are 
identified  by  a  set  of  54  Segment  Descriptor  Registers, 
wnicn  supply  tne  information  needed  to  map  logical  memory 
addresses  to  pnyscal  memory  addresses.  Each  of  tne  64 
Descriptor  Registers  contains  a  16-bit  case  address  field, 
an  8-bit  limit  field,  and  an  6-bit  attribute  field. 
Unfortunately,  tne  Z8001  nardware  was  not  available  for  use 
during  system  development.  Therefore,  all  work  to  date  has 
been  completed  through  utilization  of  tne  Z8002 
non-segmented  version  of  the  Z8000  microprocessor  family 
[17J  .  Tne  actual  hardware  used  in  this  implementation  is  the 
Advanced  Micro  Computers  Am96/4116  MonoEoard  Computer  [19j 
containing  tne  AmZ8002  sixteen  bit  non-segmented 
microprocessor.  This  computer  provides  32K  bytes  of  on-board 
RAM,  Sic  bytes  of  PROM/ROM  space,  two  RS232  serial  I/O  ports, 
24  parallel  I/O  lines,  and  a  standard  INTEL  Multibus 
interface.  The  general  structure  of  tne  design  nas  teen 
preserved  by  simulation  of  the  segmentation  hardware  in 
software.  This  software  MMU  Image  (see  Figure  8)  is  created 
as  a  database  within  the  Inner  Traffic  Controller. 
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The  MMU  Image  is  a  processor-local  database  indexed  by 
D!ER_No.  Each  DBR_No  represents  one  record  within  the  MMU 
Image.  Eacn  record  is  an  exact  software  copy  of  tne  Segment 
Descriptor  Register  set  in  tne  hardware  MMU.  Each  element  of 
this  software  MMU  Image  is  in  tne  same  form  utilized  cy  tne 
special  I/O  instructions  to  load  the  Hardware  MMU.  Each  D.BR 
record  is  indexed  cy  segment  number  (Segmen t_No ) .  Eacn 
Seement_No  entry  is  composed  of  three  fields*  £ase_Addr, 
Limit,  and  Attributes.  Base_Addr  is  a  16-bit  field  which 
contains  the  base  address  of  the  segment  in  physcal  memory. 
Limit  is  an  8-bit  field  tnat  specifies  tne  number  of 
contiguous  blocks  of  memory  occupied  by  the  segment. 
Attributes  is  an  8-bit  field  representing  the  eight  flaps 
which  specify  tne  segment's  attributes  (e.g.,  "read", 
"execute",  "write",  etc.). 

G.   SUMMARV 

An  extended  overview  of  the  current  SASS  design  has  been 
presented  in  this  chapter.  The  four  major  levels  of 
abstraction  comprising  the  SASS  system  have  been  identified 
and  the  major  components  of  eacn  level  nave  been  discussed. 
The  extended  instruction  set  provided  by  the  SAi>S  Kernel  was 
also  defined.  With  this  background,  the  actual  details  cf 
this  implementation  will  be  described  in  cnapters  III  and 
IV. 
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III.   IMPLEMENTATION  ISSUES 

Issues  bearing  on  tne  implementation  of  process 
management  and  refinements  made  to  existing  modules  are 
presented  in  tnis  chapter.  Process  management  for  the  SASS 
was  provided  through  tne  implementation  of  tne  Traffic 
Controller  Module,  tne  Event  Manager  Module,  tne  Distributed 
Memory  Manager  Module,  and  a  Gate  Keeper  Stub  (system  trap). 
Additionally,  since  a  demonstration/test  bed  was  integral  to 
tne  testing  and  verification  of  tne  implementation,  it  was 
necessary  to  complete  other  supportive  tastfs.  These 
supportive  tastes  included  limited  Kernel  database 
initialization,  revised  preempt  interrupt  handling 
mechanisms,  Idle  process  definition  and  structure,  and 
additional  refinements  to  existing  modules. 

A.   DATABASE  INITIALIZATION 

Previous  woric  on  SASS  nas  relied  on  statically  built 
databases,  wnicn  proved  to  be  sufficient  for  demonstration 
of  a  single  processor,  single  nost  supported  system.  In  the 
current  demonstration,  multiple  hosts  are  simulated,  and  tne 
Kernel  data  structures  have  been  refined  to  represent  a 
multiprocessor  environment.  Since  a  multiprocessor  system 
was  unavailable  at  the  time  of  this  demonstration,  several 
"runs"  were  made   and   traced,  using  different  logical  CPU 
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numbers,  to  snow  tne  correctness  of  this  structure.  Due  to 
this  multiprocessor  representation  and  simulation  of 
multiple  hosts,  tne  use  of  statically  built  Kernel  databases 
was  no  longer  convenient.  Therefore,  it  became  necessary  to 
provide  initialization  routines  for  tne  dynamic  creation  of 
those  Kernel  databases  required  for  this  implementation. 
While  it  was  not  tne  intent  of  tnis  effort  to  implement 
system  initialization,  care  was  tafcen  in  tne  writing  of 
these  initializing  routines  so  that  they  might  be  utilized 
in  tne  system  int iaiization  implementation  witn,  nopefuily, 
minimal  refinement.  Database  initialization  was  restricted 
to  tnose  databases  existing  in  tne  Inner  Traffic  Controller 
and  the  Traffic  Controller.  Limited  elements  of  the  Known 
Segment  Table  (KST)  and  Global  Active  Segment  Table  (G_AST) 
were  also  created  for  demonstration  purposes. 
1.   Inner  Traffic  Controller  Initialization 

A  "Eootstrap  Loader"  Module,  which  logically  exists 
at  a  higher  level  of  abstraction  within  tne  Kernel,  was 
created  to  initialize  the  databases  of  the  Inner  Traffic 
Controller.  Tnis  initialization  includes  tne  creation  of:  1) 
the  Processor  Data  Segment  (PRDS),  2)  an  MMO  Yap,  3)  Kernel 
domain  stac&  segments  for  Kernel  processes,  4)  allocation 
and  updating  of  MMU  entries  for  Kernel  processes,  and  5) 
Virtual  Processor  Table  (VPT)  entries. 

The  PRDS  was  loaded  with  constant  values  that 
specify  tne  pnysical  CPU  ID,  logical  CPU  ID,  and  rumber   of 
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VP's  allocated  to  tne  CPU.  A  design  decision  was  made  to 
allocate  logical  CPU  ID's  in  increments  of  two  (beginning 
with  zero)  so  tnat  they  could  be  used  to  directly  access 
lists  indexed  by  CPU  number.  Tne  MMU  map,  constructed  as  a 
"byte"  map,  was  created  to  specify  allocated  and  free  PMU 
Image  entries. 

A  separate  procedure,  CHEAT E_S TACK,  was  created  to 
establish  the  initial  Kernel  domain  stactf  conditions  for 
Kernel  processes.  A  discussion  and  diagram  of  tnese  initial 
stack  conditions  is  presented  in  tne  next  section. 
ALLOCATE_MMU  checks  tne  MMU  Map  and  allocates  tne  next 
availabe  MMU  entry  to  the  process  being  created.  The  PRDS  is 
inserted  in  tne  allocated  MMU  entry  and  the  E£R  number  is 
returned  to  the  calling  procedure.  The  D5R  number  (handle) 
is  merely  the  offset  of  tne  DBR  in  tne  MMU  Image.  Since  tne 

ITC  deals  with  an  address  rather  than  a  handle,  a  procedure, 
GET_CBR_ADBR ,  was  created  to  convert  this  offset  into  a 
physical  address.  UPDATE_MMU_IMAGE  is  the  procedure  which 
creates  or  modifies  MMU  Image  entries.  UPEATE_MMU_IMAGE 
accepts  as  arguments  the  DBR  number,  segment  number,  segment 
attributes,  and  segment  limits.  To  facilitate  process 
switching  and  control,  various  process  segments  must  possess 
the  same  segment  number  system  wide.  This  is  accomplished 
during  initialization  through  the  use  of  the 
UPDATE_MMU_IMAGE  procedure.  In  the  ITC,  these  segments 
include  the  PPDS  (segment  number  zero)  and  tne  Kernel  stack 
segment  (segment  number  one). 
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Tne  final  tas£  required  in  1TC  initialization  is  tne 
creation  of  tne  VPT.  The  VPT  Header  is  initialized  witn  tne 
"running"  and  "ready"  lists  pointers  set  to  a  'nil'  state, 
and  tne  "free"  list  pointer  set  to  tne  first  entry  in  tne 
message  table.  Virtual  Processor  entries  are  inserted  in  the 
main  body  of  tne  VPT  by  the  UPDATE_VP_TAiiLE  procedure. 
Entries  are  first  made  for  tne  VP's  permanently  bound  to  the 
Memory  Manager  and  Idle  processes.  Tne  VP  bound  to  the  MM 
process  is  given  a  priority  of  2  (highest),  and  the  VP  bound 
to  the  Idle  process  is  given  a  priority  of  0  (lowest).  The 
External  VP  ID  for  doth  of  tnese  VP's  is  set  to  "nil"  as 
they  are  not  visible  to  the  Traffic  Controller.  The 
remaining  VP's  allocated  to  the  CPU  (viz.,  TC  visible  VP's) 
are  then  entered  in  the  VPT  with  a  priority  of  1 
(intermediate),  and  tneir  "idle"  and  "preempt"  flags  are 
set.  The  preempt  flag  is  set  for  these  TC  visible  VP's  to 
insure  proper  scneduling  by  tne  Traffic  Controller.  Tne  EBP. 
for  these  remaining  VP's  is  initialized  with  the  Idle 
process  PER.  A  discussion  of  "idle"  processes  and  VP's  will 
be  provided  later  in  this  chapter.  The  External  VP  ID  for 
each  TC  visible  VP  is  merely  tne  offset  of  the  next 
available  entry  in  tne  EXTERNAL  VP  LIST.  This  External  VP  ID 
is  entered  in  tne  VPT,  and  tne  corresponding  VP  ID  (viz., 
VPT  Entry  ft)    is  entered  in  the  EXTERNAL  VP  LIST. 

Once  tnese  VPT  entries  nave  been  made,  it  is 
necessary  to  set  tne  state  of  each  VP  to  "ready"  and   thread 
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them  (by  priority)  into  tne  appropriate  ready  list.  A  VPT 
threading  mechanism  was  provided  by  Reitz  [5]  in  procedure 
MAKE_READY.  However,  it  was  desired  to  nave  a  more  general 
threading  mechanism  that  could  be  used  for  other  lists. 
Procedure  LIST_INS£RT  was  created  to  provide  tni s  general 
threading  mechanism.  LIST_INSERT  is  logically  a  "library" 
function  tnat  exist?  at  tne  lowest  level  of  abstraction  in 
the  Kernel.  This  function  threads  an  object  into  a  list 
(specified   by   the   caller)   in  order  of  priority,  and    tnen 

sets  its  state  as  specified  by  the  calling  parameters. 

Once  tne  "Bootstrap  Loader"  has  completed  ITC 
initialization,  it  passes  control  to  tne  ITC  GETTtf03K 
procedure  to  begin  VP  scneduling. 

2.   Traffic  Controller  Initialization 

The  initialization  routines  for  tne  TC  include 
TC_INIT,  .  C?EATE_PROCESS,  and  CREATS_KST.  These  routines  are 
called  from  the  Memory  Manager  process.  Tne  MM  process  was 
chosen  to  initiate  these  routines  as  it  is  bound  to  tne 
nighest  priority  VP  and  will  be^in  running  immediately  after 
the  Inner  Traffic  Controller  is  initialized.  Procedure 
MM_ALLOCATE  was  written  to  allocate  memory  space  for  data 
structures  during  initialization  (viz.,  Kernel  stacks,  user 
stacks,  and  KST's).  Memory  space  is  allocated  in  blocKs  of 
100  (hex)  bytes.  MM_AILOCATE  is  merely  a  stub  of  the  memory 
allocating  procedure  designed  by  Moore  and  Gary  [4j  . 
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It  was  necessary  to  pass  long  lists  of  arguments  to 
tne  TC  for  initialization  purposes.  To  ail  in  this  passing 
of  parameters,  a  data  structure  template  was  used.  This 
template  was  created  by  declaring  tne  parameters  as  a  data 
structure  in  both  the  sending  and  receiving  procedures,  and 
then  imaging  this  structure  at  absolute  address  zero.  The 
process'  stack  pointer  was  tnen  decremented  ty  tne  size  of 
the  parameter  data  structure,  and  the  parameters  were  loaded 
into  tnis  data  structure  indexed  by  tne  stack  pointer.  This 
template  made  it  very  easy  to  send  and  receive  lone  argument 
lists  using  tne  process'  stack  segment. 

TC_INIT  initializes  the  APT  header  and  virtual 
interrupt  vector  (discussed  later).  Each  element  of  tne 
running  list  is  marked  "idle",  the  ready  and  blocked  lists 
are  set  to  "nil",  and  the  number  of  VP's  and  first  VP  for 
each  CPU  are  entered  in  the  VP  table.  The  address  of  the 
virtual  preempt  handler  is  then  passed  to  the  ITC  procedure 
CREATE_INT_7EC  for  insertion  in  tne  virtual  interrupt 
vector. 

CREATE_PROCiSS  intiaiizes  user  processes  and  creates 
entries  in  the  APT.  ALLOCATE_MMU  is  called  to  acquire  a  DPR 
number,  and  an  APT  entry  is  created  with  tne  process 
descriptors  (viz.,  parameters).  Tne  process  is  then  declared 
"ready"  and  tnreaded  into  the  approciate  ready  list  by 
calling  the  threading  function,  LIST_INSERT.  A  user  stack  is 
allocated  and  UPDAT£_MMU_Ir"AGE  is  called  to  include  the  user 
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stack  in  the  MMU  as  segment  number  three.  The  user  stack 
contains  no  information  or  user  process  initialization 
parameters  (viz.,  execution  point  and  address  space)  as  all 
processes  are  initialized  and  begin  execution  from  the 
Kernel  domain.  Next,  a  Kernel  domain  stack  is  allocated  and 
included  in  the  MMU  Image.  A  design  decision  was  made  to 
initialize  the  Kernel  stacks  for  user  processes  witn  tne 
same  structure  as  the  Kernel  process'  stacks.  The  rationale 
for  this  decision  is  presented  in  tne  next  section.  As  a 
result  of  this  decision,  it  became  possible  to  use  the 
CREATE_STACK  procedure  in  bui  Iding^  Kernel  domain  stacks  for 
both  Kernel  and  user  prosesses.  CREATE_STACK  was  therefore 
used  as  a  library  function  and  placed  in  the  library  module 
with  LIST-INSERT. 

Finally,  a  Known  Segment  Table  (KST)  stub  is  created 
to  provide  a  means  of  demonstrating  the  mechanism  provided 
by  the  eventcounts  and  sequencers  for  interprocess 
communication  (IPC)  and  mutual  exclusion.  Space  for  the 
process'  KST  is  created  by  calling  MM_ALLOCATE.  The  KST  is 
then  included  in  the  process'  address  space,  as  segment 
number  two,  by  UPDATE_MMU_IMAGE.  Initial  entries  are  made  in 
the  Known  Segment  Table  by  procedure  CREATE_KST.  CREATE_KST 
mases  an  entry  in  the  KST  for  the  "root"  and  marits  tne 
remaining  KST  entries  as  "available."  Tne  Unique_ID  portion 
of  the  root's  handle  (viz.,  upper  two  words)  is  initialized 
as  -1  (for  convenience)  and  tne  G_AST  entry  number  portion 
of  the  handle  (viz.,  lowest  word)  is  initialized  with  zero. 
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3.   Additional  Initialization  Requirements 

As  already  mentioned,  the  Memory  Manager  Process 
prepares  tne  arguments  utilized  Dy  TC_INIT,  CREATE_PRCCESS , 
and  CREATE_KST  for  TC  initialization  and  user  process 
creation.  Additionally,  tne  MM  process  creates  a  Global 
Active  Segment  Table  (G_AST)  stub  utilized  for  demonstration 
of  event  data  management.  The  G_AST  stub  is  declared  in  a 
separate  module  (viz.,  the  DEMO_DATABASE  Module)  with  tne 
format  prescribed  by  Moore  and  Gary  14J  .  However,  the  only 
fields  initialized  and  utilized  by  this  implementation  are 
UNI0UE_ID,  SEQUENCER,  INSTANCE  1,  and  INSTANCE  2.  The 
eventcounts  and  sequencer  fields  are  initialized  as  zero 
whenever  an  entry  is  created  in  the  G_AST.  The  UNigUE_ir  is 
created  just  to  support  this  demonstration  and  does  not 
reflect  the  segment's  unique  identifier  as  specified  by 
Moore  and  Gary  [4j .  In  tnis  demonstration,  UNIOUE_IE  is 
built  with  the  parameters  passed  to  MM_ACTIVATE.  The  first 
word  in  UNIOUE_ID  is  tne  G_AST  entry  number  of  tne  segment's 
parent,  and  the  second  word  is  the  segment's  entry  number 
into  tne  alias  table.  Tne  UNI0UE_ID  to^etner  with  tne  offset 
of  the  segment's  entry  in  the  G_AST  comprise  the  segment 
HANDLE  maintained  in  tne  KST.  Tne  first  entry  in  tne  G_AST 
is  reserved  for  the  root,  and  is  initialized  with  an 
Unique_ID  of  minus  one  (-1).  It  snould  be  noted  tnat  acy 
call  to  MM_ACTIVATE  for  a  segment  already  possessing  an 
entry  in   tne  G_AST  will   not   effect  any  cnanges  to  that 
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entry.  This  is  to  insure  tnat  a  single   G_AST   entry   exists 
for  every  segment  as  specified  by  Moore  and  Gary  [4j . 

B.   PREEMPT  INTERRUPTS 

Various  refinements  were  made  in  the  handling  of  ootn 
pnysical  (nardware)  and  virtual  (software)  preempt 
interrupts.  A  hardware  preempt  is  a  non-vectored  interrupt 
tnat  invokes  tne  virtual  processor  scneduling  mecnanism 
(viz.,  ITC  GETWORK).  A  virtual  preempt  is  a  software 
vectored  interrupt  tnat  invokes  tne  user  process  scneduling 
mechanism  (viz.,  TC_GETWORK).  Tnis  implementation  provides 
tne  notion  of  a  virtual  interrupt  tnat  closely  mirrors  tne 
behavior  of  a  hardware  interrupt.  In  particular,  there  are 
similar  constructs  for  initialization  of  a  nandler, 
invocation  of  a  handler,  masking  of  interrupts,  and  return 
from  a  handler.  As  with  most  hardware  interrupts,  a  virtual 
interrupt  can  occur  only  at  the  completion  of  execution  for 
an  "instruction,"  wnere  each  kernel  entry  and  exit  for  a 
process  delimit  a  single  "virtual  instruction." 

1.   Physical  Preempt  Handler 

Tne  pnysical  preempt  nandler  resides  in  the  virtual 
processor  manager  (viz.,  Inner  Traffic  Controller).  The 
functions  it  perform  are:  1)  save  tne  execution  point,  2) 
invoice  ITC  GETWORK,  3)  checX  for  virtual  preempt  interrupts, 
4)  restore  the  execution  point,  and  5)  return  control  via 
the   IRET   instruction.   Reitz   [5]   included   tne   hardware 
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preempt  nandler  in  ITC  GETWORK  by  establishing  two  entry 
points  and  two  exit  points,  one  for  a  regular  call  to 
GETWORK  and  another  for  the  preempt  interrupt.  He  had  a 
separate  procedure,  TEST_PREEMPT  ,  that  was  used  to  checi  for 
the  occurrence  of  virtual  preempt  interrupts.  This  structure 
worlcs  nicely,  but  it  requires  some  means  of  determining  how 
GETWORK  was  invoked  so  that  the  proper  exiting  mechanism  is 
used.  This  was  resolved  by  incorporating  a  preempt  interruDt 
flag  in  the  status  register  blocK  of  every  process'  Kernel 
domain  stacfc  segment.  A  design  decision  was  made  to 
restructure  the  hardware  preempt  handler  into  a  single  and 
separate  procedure,  PHyS_PREEMPT_HANDLER.  This  allowed  ITC 
GETWORK  to  have  a  single  entry  and  exit  point,  and  it  did 
away  witn  the  necessity  of  maintaining  a  preempt  interrupt 
flag  in  the  process  stacks.  PK*S_PRESMPT_PANDLER  was 
constructed  from  the  preempt  handling  code  in  GETWORK  and 
procedure  TEST_PREEMPT.  TEST_PREE*pt  was  deleted  from  the 
ITC  as  its  functions  were  performed  by  PHYS_PREEMPT-HANELER . 
A  further  refinement  was  made  to  the  hardware 
preempt  handler  dealing  with  the  netnod  by  wnicn  tne  virtual 
preempt  handler  was  invoiced.  3eitz  [5J  invoked  the  virtual 
preempt  nandler  from  TEST_PREEMPT  by  means  of  tne  "call" 
instruction.  Since  the  virtual  preempt  nandler  logically 
exists  at  a  nigner  level  of  abstraction  tnan  the  ITC,  tnis 
invocation  violated  our  notion  of  only  allowing*  "calls"  to 
lower  or  equal  abstraction  levels.  However,   this   deviation 
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was  necessitated  by  the  absence  or  a  virtual  interrupt 
structure.  Tnis  problem  was  alleviated  by  creating  a  virtual 
interrupt  vector  in  the  ITC  that  is  used  in  tne  sane  way  as 
tne  hardware  interrupt  vector.  Tne  virtual  preempt  was  given 
a  virtual  interrupt  number  (zero).  Tne  virtual  interrupt 
handler  is  then  invoked  by  means  of   a   "jump"   tnrougn   the 

virtual  interrupt  vector  for  virtual  interrupt  number  0. 
This  invocation  occurs  in  tne  same  manner  that  tne  nandlers 
for  hardware  interrupts  are  invoiced.  The  virtual  interrupt 
vector  is  created  by  procedure  CREATE_INT_VEC. 
CREAT£_INT_VEC  accepts  as  arguments  a  virtual  interrupt 
number  and  the  address  of  the  interrupt  handler.  Tne 
creation  of  tne  virtual  preempt  entry  in  the  virtual 
interrupt  vector  is  accomplished  at  tne  time  of  the  Traffic 
Controller  initialization  by  TC_INIT. 
2.   Virtual  Preempt  Handler 

The  virtual  preempt  handler  (VIRT_PR2EMPT_HANELER ) 
resides  in  the  user  process  manager  (viz.,  the  Traffic 
Controller).  The  functions  performed  by  VIRT_PREEMPT_EANPLER 
are:  1^  determine  the  V?  ID  of  the  virtual  processor  beina* 
preempted,  2)  invoke  the  nrocess  scneduling  mechanism  (viz., 
TC_GETWORK),  and  3)  return  control  via  a  virtual  interrupt 
return.  The  correct  VP  ID  is  obtained  by  calling  RUNNING_VP 
in  the  ITC.  The  Active  Process  Table  is  then  locked,  and'  the 
state  of  tne  process  running  on  tnat  VP  is  changed  to 
"ready."   At   this   time,   process  scheduling  is  effected  by 
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calling  TC_C-ETWORK.  Once  process  scnedulin^  is  completed, 
the  APT  is  unlocked  and  control  is  returned  via  a  virtual 
interrupt  return.  Tnis  virtual  interrupt  return  is  merely  a 
jump  to  tne  PPE.L'MFT_P£T  label  in  tne  Hardware  preempt 
nandier  (Tnis  jump  emulates  tne  action  of  tne  IRDT 
instruction  for  a  nardware  interrupt  return).  Tnis  label  is 
tne  point  at  wnich  the  virtual  preempt  interrupts  are 
unmasked . 

All  Kernel  processes  are  initialized  to  appear  as 
tnougn  tney  are  returning  from  a  nardware  preempt  interrupt. 
All  user  processes  initially  appear  to  be  returning  from  a 
virtual  preempt  interrupt.  Therefore,  tne  initial  conditions 
of  a  process'  Kernel  domain  stack  is  largely  influenced  by 
tne  stack  manipulation  of  tne  preempt  handlers.  Figure  9 
illustrates  the  initial  Kernel  domain  stack  structure  for 
all  system  processes. 

The  initial  Kernel  Flag  Control  Word  (FCW)  value  is 
"5000"f    indicating  non-segmented   code,   system  mode   of 

operation,  non-vectored  interrupts  masked,  and  vectored 
interrupts  enabled.  The  Current  StacK  Pointer  value  is  set 
to  the  first  entry  in  the  stack  (viz.,  SP).  The  IPET  Frame 
is  tne  portion  of  tne  Kernel  stack  affected  by  tne  IP.5T 
instruction.  The  first  element,  Interrupt  ID  (set  to  "FFFF") 
is  merely  popped  off  of  tne  stack  and  discarded.  The  next 
element.  Initial  FCW,  is  popped  and  placed  in  tne  system 
Flag  Control  Word.  Initial  FCW  is  set  to  "50ee"   for   Kernel 
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processes  and  "18450"  (indicating  normal  mcae  witn  ail 
interrupts  enabled)  for  user  processes.  The  final  element  of 
tne  IRE?  frame.  Initial  IC  is  popped  off  of  tne  stacK  and 
placed  in  tne  program  counter  (PCM  register.  Tnis  value  is 
initialized  as  tne  entry  address  of  tne  process  in  auesticn. 
The  "register"  entries  on  tne  stac£  represent  tne 
initial  register  contents  for  tne  process  at  tne  beginning 
of  its  execution.  Since  tne  Kernel  processes  (viz.,  MM  and 
Idle)  do  not  require  any  specific  initial  register  states, 
their  entries  reflect  the  register  contents  at  tne  time  of 
stack  creation.  Initial  register  conditions  are  used  to 
provide  initial  "parameters"  required  fey  the  user  processes. 
This  will  depend  largely  upon  tne  parameter  passing 
conventions  of  the  implementation  language.  The  means  for 
register  initialization  was  provided  through  CREATE_PRCCESS ; 
however,  the  only  initial  register  condition  used  for  the 
user  processes  in  this  demonstration  was  register  #13. 
Register  #13  was  used  to  pass  tne  user  ID/Host  number  of  tne 
process  created.  This  value  is  utilized  by  the  user  process 
in  activating  the  segment  used  for  inter-process 
communication  between  a  Host's  File  manager  and  I/O 
processes.  Another  logical  parameter  passed  to  the  user 
processes  is  the  root  segment  number.  This  did  not  require  a 
register  for  passing  in  the  demonstration  as  it  is  known  to 
be  the  first  entry  in  the  KST  for  all  processes.  The  N_S_P 
entry  on  the  stack   represents   tne   initial   value   of   the 
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normal  stack  pointer.  For  user  processes,  this  value  is 
obtained  wnen  tne  Supervisor  domain  stack  for  tnat  process 
is  created.  For  Kernel  processes,  this  value  is  set  to 
"FFFF"  since  tney  execute  solely  in  the  Kernel  domain  and 
have  no  Superivsor  domain  stack.  The  Preempt  Return  Point 
specifies  tne  address  wnere  control  will  be  passed  once  the 
process'  ^P  is  scheduled  and  the  "return"  from  ITC  GETWORK 
is  executed.  For  Kernel  processes,  this  is  tne  point  within 
the  hardware  preempt  nandier  where  the  virtual  processor 
table  is  unlocked.  For  user  processes,  this  is  tne  point 
within  the  virtual  preempt  handler  where  the  Active  Process 
Table  is  unlocked. 

It  is  important  to  note  that  if  the  APT  was  not 
unlocked  when  a  user  process  bee-an  its  initial  execution, 
the  system  would  become  deadlocked  and  no  further  process 
scheduling  could  occur.  It  should  be  further  noted  that  the 
initial  stack  conditions  for  user  processes  do  not  reflect  a 
valid  history  of  execution.  The  "norrral"  history  of  a  user 
process  returning  from  ITC  GETWOPK  after  a  virtual  preempt 
interrupt  would  reflect  the  passing-  of  control  throug-h 
S*AP_VD3R  and  TC_GETWORK  to  the  point  in  the  virtual  preempt 
handler  where  the  APT  is  unlocked.  Another  "possible" 
history  could  reflect  tne  occurrence  of  a  nardware  preempt 
interrupt  at  the  point  in  the  virtual  preempt  handler  where 
tne  APT  is  unlocked.  Such  a  nistory  would  be  depicted  by 
replacing  the  current  top  of  the  stack  with  the  return  point 
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into  the  hardware  preempt  handler  (viz.,  at  the  point  of 
virtual  preempt  interrupt  unmasking)  and  an  additional 
hardware  preempt  interrupt  frame  whose  IC  value  In  the  IPJ2T 
frame  is  the  point  in  the  virtual  preempt  nandier  where  the 
APT  is  unlocked.  The  current  initial  stack  condition  for 
user  processes  was  cnosen  for  its  ease  of  understanding  and 
its  clear  depiction  of  the  fact  that  the  structure  of  a 
Kernel  domain  stack  is  the  same  for  both  Kernel  and  user 
processes  . 

C.   IDLE  PROCESSES 

In  the  SASS  design,  there  logically  exists  a  Kernel 
domain  "idle"  process  for  every  physical  processor  in  the 
system  and  a  Supervisor  domain  "idle"  process  for  every  "TC 
visible"  virtual  processor  in  the  system.  These  processes 
are  necessary  to  insure  tnat  both  tne  VP  scheduler  (viz., 
ITC  GETWORK)  and  the  process  scheduler  (TC_GETWORK)  will 
always  nave  some  object  to  schedule,  nence  precluding  any 
CPU  or  VP  from  ever  having  an  undefined  execution  point. 
Since  the  Kernel  domain  Idle  process  performs  no  useful 
work,  it  could  be  included  within  the  ITC  by  means  of  an 
infinite  looping  mechanism.  Tne  Kernel  Idle  process  was 
maintained  separately,  however,  as  it  is  hoped  that  future 
work  on  SASS  will  provide  this  Idle  process  with  some 
constructive  purpose  (e.,?.,  performing  maintenance 
diagnostics) . 
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The  Supervisor  domain  Idle  processes  (nereafter  referred 
to  as  TC  Idle  processes)  are  scheduled  (bound)  on  VP's  when 
there  are  no  user  processes  awaiting  scheduling.  Since  a  TC 
Idle  process  performs  no  user  constructive  worfc,  we  do  not 
want  any  VP  executing  a  TC  Idle  process  to  be  bound  tc  a 
physical  processor.  In  other  words,  a  VP  bound  to  a  TC  Idle 
process  assumes  the  lowest  system  nriority  (represented  by 
the  "idle  flag").  Therefore,  any  such  VP  will  have  its  idle 
flag  set  and  will  not  be  scheduled  unless  it  receives  a 
virtual  preempt  interrupt.  Such  an  interrupt  will  allow  the 
V?  to  be  rescneduled  by  tne  Traffic  Controller.  It  should  be 
obvious,  at  this  point,  that  a  TC  Idle  process  will  never 
actually  begin  execution  on  a  real  processor.  This  knowledge 
allowed  a  design  decision  to  be  made  to  only  simulate  the 
existence  of  TC  Idle  processes.  At  tne  TC  level,  this  was 
accomplished  by  a  constant  value,  IDLE_?R0C,  that  was  used 
as  a  process  ID  in  tne  APT  running  list,  thus  precluding  the 
necessity  of  any  "idle"  entries  in  the  APT.  At  the  ITC 
level,  any  VP  marked  "idle"  (viz.,  tne  idle  flag  set)  was 
given  the  DPR  number  (viz.,  address  space)  of  the  Kernel 
Idle  process  solely  to  provide  the  use  of  a  Kernel  domain 
stacs  for  rescheduling  of  the  VP. 

D.   ADDITIONAL  KERNEL  REFINEMENTS 

In  addition  to  those  already  discussed,  several  other 
refinements  to  existing  Kernel  modules  were  effected  in  this 
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implementa  ti  on.  One  of  tnese  refinements  deals  with  the  way 
virtual  processors  are  identified  by  the  Traffic  Controller. 
In  the  current  implementa ti on ,  all  TC  visible  virtual 
processors  are  *?iven  an  External  VP  ID  which  corresponds  to 
its  entry  number  in  an  External  VP  list.  This  required  a 
modification  to  the  ITC  procedure  RUNNING_VP.  The  benefits 
derived  from  tnis  refinement  included  the  ability  to 
directly  access  the  External  VP  ID  in  the  Virtual  Processor 
Table  vice  the  requirement  of  a  run  time  division  to  compute 
its  value  and  the  ability  to  use  the  External  V?  ID  as  an 
index  intc  the  TC  running  list. 

Refinements  were  also  made  to  the  existing  Memory 
Manager,  File  Manager,  and  10  process  stucs  used  for 
demonstration  purposes.  These  refinements  were  largely 
associated  with  the  eventcount  and  sequencer  mecnanisms 
utilized  in  this  implementation.  The  current  status  of  these 
processes  is  provided  in  a  report  by  Scnell  and  Cot  [22J  . 

The  remaining  refinements  deal  largely  with  the  MMU 
Image.  In  Moore  and  Gary's  [4j  design,  tne  MMU  Image  was 
managed  by  the  Memory  Manager  process.  This  was  largely 
because  tne  MMU  Image  is  a  processor  local  database  and 
would  seem  well  suited  for  management  by  the  non-distributed 
Kernel.  In  fact,  tne  MMU  Image  is  utilized  mainly  by  tne  ITC 
for  the  multiplexing  of  process  address  spaces.  Therefore, 
in  the  current  design,  tne  MMU  Images  are  maintained  by  the 
Inner  Traffic   Controller,  however,  the  MMU  header  proposed 
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by  Moore  ana  Gary  (viz.,  the  BLOCKS_USED  and 
MAXIMUM_A7AILAELE-EL0CKS  fields)  was  retained  in  the  Memory 
Manarer  as  it  is  used  strictly  in  tne  management  of  a 
process'  virtual  core  and  is  not  associated  with  the 
Hardware  MMU. 

In  Cells'  design  [6J ,  the  Traffic  Controller  used  tne 
linear  ordering  of  the  DEH  entries  in  the  MMU  Image  as  the 
DER  nandle  (viz.,  1,2,3...).  This  required  a  run  time 
division  operation  to  compute  the  DER  number,  and  a  run  time 
multiplication  operation,  by  MM_GET_DBR_VALUE ,  tc  recompute 
the  DER  address  for  use  by  the  ITC.  In  the  current  design, 
the  offset  of  the  DER  entry  in  the  MMU  Image  (obtained  at 
the  time  of  MMU  allocation)  is  used  as  the  DER  handle  in  the 
Traffic  Controller.  Furthermore,  SWAF_VDSR  was  refined  to 
accept  a  DER  handle  rattier  than  a  DER  address  to  preclude 
the  necessity  of  the  Traffic  Controller  naving  to  deal  with 
MMU  addresses.  DiR  addresses  are  computed  only  within  the 
ITC  (viz.,  by  procedure  GET_DS?._ADDR )  by  adding  tne  value  of 
the  DER  handle  to  the  base  address  of  the  MMU  lma^e.  Since 
DER  addresses  are  now  used  solely  within  tne  ITC.  procedure 
vm_GET_DER_v"ALtJE  was  no  longer  needed  and  was  deleted  from 
the  Memory  Manager. 

E.   SUMMARY 

The  primary  issues  addressed  in  this  thesis  effort  have 
been  presented  in   this   chapter.   Aside   from   the   process 
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management  functions,  tnis  description  included  a  mecnanism 
for  limited  Kernel  database  initialization,  a  revised 
preempt  interrupt  nandling  mecnanism,  tne  creation  of  a 
virtual  interrupt  structure,  a  definition  of  "idle" 
processes  and  tneir  structure,  and  a  discussion  of  tne  minor 
refinements  effected  in  existing  SASS  modules.  A  detailed 
description  of  tne  implementation  of  process  management 
functions  for  tne  SASS  is  nresented  in  tne  next  chaster. 
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17.   PROCESS  MANAGEMENT  IMPLEMENTATION 

Tne  implementation  of  process  management  functions  and  a 
gate  deeper  stub  (system  trap)  is  presented  in  tnis  cnapter. 
Tne  implementation  is  discussed  in  terms  of  tne  Event 
Manager,  Traffic  Controller,  Distributed  Memory  Manager, 
User  Gate,  and  Kernel  Gate  Keeper  modules.  A  tiocic  diagram 
depicting  tne  structure  and  interreiationsnips  of  these 
modules  is  presented  in  figure  10.  Support  in  developing-  tne 
Z8000  macnine  code  for  tnis  implementation  was  provided  by  a 
ZilOff  MCZ  Developmental  System  operating  under  tne  P10 
operating  system.  Tne  Developmental  System  provided  disir 
file  management  for  a  dual  drive,  nard  sectored  floppy  disur, 
a  line  oriented  text  editor,  a  PLZ/ASM  assembler,  a  linker 
and  a  loader  tnat  created  an  executable  image  of  earn  zefcjee 
load  module.  An  upload/download  capability  with  tne 
Am96/4116  MonoBoard  computer  was  also  provided.  This 
capability,  along  witn  tne  general  interfacing  of  tne 
Am96/4116  into  the  SASS  system,  was  accomplished  in  a 
concurrent  thesis  endeavor  by  Gary  Baser.  Baiter's  worlc 
relating  to  hardware  initialization  in  SASS,  will  be 
published  upon  completion  of  his  thesis  work  in  June  1981. 


76 


Traffic  Controller 


MM  Read  Eventcount 


MM  Ticket 


MM  Advance 


Distributed  Memory  Manager 


Figure  10.  Implementation  Module  Structure 


7? 


A.   EVENT  MANAGER  MODULE        _ 

The  eventcount  and  sequencer  primitives  [15J  ,  whim  are 
system-wide  objects,  collectively  comprise  the  event  data  of 
SASS.  As  mentioned  earlier,  this  event  data  is  tied  directly 
to  system  segments  and  is  stored  in  the  Global  Active 
Segment  Table.  There  are  two  ever.tcounts  and  one  sequencer 
for  every  segment  in  the  system.  These  objects  are 
identified  to  the  Kernel  in  user  calls  by  specification  of  a 
segment  number.  Once  this  segment  number  is  identified  by 
the  Kernel,  tne  segment's  handle  can  be  obtained  from  tne 
process'  Known  Segment  Table.  The  segment  nandle  identifies 
the  particular  entry  in  tne  G_AST  containing  tne  event  data 
desired. 

Tne  Event  Manager  module  manages  the  event  data  within 
the  system  and  provides  the  mechanism  for  interprocess 
communication  between  user  processes.  The  Event  Manager 
consists  of  six  procedures.  Tour  of  these  (Advance,  Await, 
Read,  and  Ticket)  represent  tne  four  user  extended 
instructions  provided  by  the  Event  Manager.  The  remaining 
two  procedures  provide  internal  computational  support  to 
include  necessary  security  checking.  Tne  Event  Manager  is 
invoiced  solely  by  user  processes,  via  tne  Gate  Keeper, 
through  utilization  of  the  extended  instruction  set 
provided.  For  every  Event  Manager  extended  instruction 
invoked  by  a  user  process,  the  non-discretionary  security  is 
verified  by  comparing  the  security  access  classification   of 
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tne  process  invoking  tne  instruction  witn  tne  classification 
of  the  object  (segment)  being  accessed.  Access  to  the  user 
process'  Known  Segment  Table  is  required  by  tne  module  in 
order  to  ascertain  tne  segment  nandle  and  security  class  for 
a  ffiven  segment  number.  The  PIZ/ASM  assembly  lan2ua.ee 
listing  for  the  Event  Manager  module  is  provided  in  Appendix 
A.  A  more  detailed  discussion  of  the  procedures  comprising 
the  Event  Manager  follows. 
1.   Support  Procedures 

The  procedures  GET_HANDL£  and  CONVERT_AND_VERIEY 
provide  internal  support  for  tne  Event  Manager  and  are  not 
visible  to  tne  user  processes.  Procedure  CONVERT_AND_VERIIY 
is  invoiced  by  the  four  procedures  representing  the 
instruction  set  of  the  Event  Manager.  The  input  parameters 
to  CON^SP.T_AND_VEHIET  are  a  segment  number  and  a  requested 
mode  of  access  (viz.,  read  or  write).  C0N7ERT_AND_VER1FY 
returns  a  pointer  to  the  segment's  handle  and  a  success 
code.  Procedure  GET_HANDLE  is  invoiced  solely  by 
CONVERT_AND_VEPIFT.  The  input  parameter  to  GET_HANi;LE  is  the 
segment  number  received  as  input  by  CONV"ERT_ANr_VERIET . 
GET_HANDLE  returns  a  pointer  to  tne  segment's  handle,  a 
pointer  to  tne  segment's  security  classification,  and  a 
success  code.  A  discussion  of  the  functions  provided  by 
these  support  procedures  follows. 

Procedure  GJ!iT_RANDLE  translates  the  segment  number, 
received  as  input,  into  a  KST  index  number  and  verifies  that 
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the  resulting  index  number  is  valid.  Next  the  base  address 
of  tne  process'  KST  is  obtained  from  procedure 
ITC_GET_SEG_?TR.  Tne  KST  index  number  is  tnen  converted  into 
a  KST  offset  value  and  added  to  tne  base  address  to  obtain 
tne  appropriate  KST  entry  pointer  for  tne  segment  in 
question.  A  verification  is  tnen  made  to  insure  tnat  tne 
referenced  segment  is  "known"  to  tne  process.  If  tne  segment 
is  not  Known,  an  error  message  is  returned  to 
CONVERT_AND_VERIFY.  Otnerwise,  a  pointer  to  tne  segment's 
nandie  is  obtained  to  identify  tne  segment  to  the  memory 
manager.  A  pointer  to  tne  segment's  security  class  entry  in 
tne  KST  is  also  returned  for  use  in  appropriate  security 
cnecfcs . 

Procedure  CONVERT_AND_VERIFY  provides  tne  necessary 
non-discretionary  security  verification  for  tne  extended 
instruction  set  of  the  Event  Manager.  Procedure  GET_HANDLE 
is  invoked  for  segment  number  verification  and  to  obtain 
pointers  to  the  segment's  handle  and  security  class.  If 
GET_HANDLE  returns  witn  a  successful  verification,  tne 
process'  security  class  is  compared  to  tne  segment's 
security  class  to  verify  the  mode  of  access  requested.  A 
request  for  "write"  access  causes  invocation  of  the  CIASS_E0 
function  in  the  Non-Di scretionary  Security  Module  to  insure 
that  the  security  classification  of  the  process  is  equal  to 
the  classification  of  the  eventcount  or  sequencer,  which  is 
the  same  as  that  of  the   segment.   Otherwise,   the   CLASS_GE 
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function  is  called  to  verify  that  the  process  has  read 
access.  If  tne  appropriate  security  cnecic  is  unsuccessful, 
an  error  code  is  returned  by  CONVEKT_AND_VERIFY .  Otherwise, 
tne  segment  nandie  is  returned  along  with  a  success  code  of 
"succeeded"  indicating  that  tne  user  process  possesses  the 
necessary  security  clearance  to  complete  execution  of  tne 
extended  instruction. 

2.  Read 

Procedure  READ  ascertains  tne  current  value  of  a 
user  specified  eventcount  and  returns  its  value  to  the 
caller.  Tne  input  parameters  to  READ  are  a  segment  number 
and  an  instance  (viz.,  an  event  number).  CONVERT_AND_VERIFY 
is  invoked  with  a  "read"  access  request  to  obtain  tne 
segment's  handle  and  necessary  verification.  "Read"  access 
is  sufficient  for  this  operation  as  it  only  requires 
observation  of  tne  current  eventcount  value  and  performs  no 
data  modification.  If  verification  is  successful,  procedure 
MM_READ_EVENTCOUNT  is  called  to  obtain  tne  eventcount  value. 

3.  TicKet 

Procedure  TICKET  returns  tne  current  sequencer  value 
for  the  segment  specified  by  the  user.  CONVERT_ANr_VERIIX  is 
called  with  a  request  for  write  access  to  obtain 
verification  and  the  segment  handle.  Write  access  is 
required  because  once  the  sequencer  value  is  read  it  must  be 
incremented  in  anticipation  of  the  next  ticket  request.  Once 
verification    is   complete,    MM_TICKET    is    invoked    to    obtain   the 
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sequencer  value  that  is  returned  to  the  user  process.  It  is 
noted  that  every  call  to  TICKET  for  a  particular  segment 
number  will  return  a  unique  and  time  ordered  sequencer 
value.  Tnis  is  because  the  sequencer  value  may  oniy  be  read 
within  MP*_TICK£T  wnile  the  G_AST  is  loc&ed,  thereby 
preventing  simultaneous  read  operatiors.  Euthermore,  once 
the  sequencer  value  is  read  it  is  incremented  before  the 
G_AST  is  unlocked. 

4.   Await 

Procedure  AWAIT  allows  a  user  process  to  block 
itself  until  some  specified  event  has  occurred.  The 
parameters  to  AWAIT  include  a  segment  number  and  instance, 
which  identify  a  particular  event,  ana  a  user  specified 
value  which  identifies  a  particular  occurrence  of  the  event. 
Verification  of  read  access  and  a  pointer  to  tne  segment's 
handle  is  obtained  from  procedure  CONVERT_AND_VEHIJ! . 
Procedure  TC_AWAIT  is  invoiced  to  effect  tne  actual  waiting 
for  the  event  occurrence.  TC_AWAIT  will  not  return  to  AWAIT 
until  the  requested  event  has  occurred.  It  is  ncted  that 
AWAIT  makes  no  assumptions  about  the  event  value  specified 
*y  the  user.  Therefore,  the  Kernel  cannot  guarantee  that  the 
event  specified  by  the  user  will  ever  occur;  this  is  the 
responsibility  of  other  cooperating  user  processes. 

b.   Advan^P 

Procedure  AL^ANCE  allows  a  user  process  to  broadcast 
the   occurrence      of     some      event.      This      is      accomplished      by 
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incrementing  tne  value  of  tne  eventcount  associated  witn  tne 
event  that  has  occurred.  Tne  parameters  to  ADVANCE  include  a 
segment  number  and  instance  wnicn  identify  a  particular 
event.  Tne  calling  process  must  nave  write  access  to  the 
identified  segment  as  modification  of  tne  eventcount  is 
required.  Verification  of  write  access  and  a  pointer  to  tne 
segment's  handle  is  obtained  through  procedure 
C0NV£RT_AND_VERIFY.  Procedure  TC_ADVANCE  is  invoked  to 
perform  the  actual  broadcasting  of  event  occurrence. 

E.  TRAFFIC  controller  module 

The  primary  functions  of  the  Traffic  Controller  module 
are  user  process  scneduling  and  support  of  tne  inter-process 
communication  mechanism.  The  Traffic  Controller  is  invoiced 
by  tne  occurrence  of  a  virtual  preempt  interrupt  and  by  tne 
Event  Manager  and  the  Segment  Manager  tnrougn  tne  extended 
instruction  set:  TC_Advance.  TC_Await,  Process_Class  ♦  and 
Get_DER_NTJMBSR.  The  Traffic  Controller  module  is  comprised 
of  nine  procedures.  Four  of  tnese  procedures  represent  tne 
extended  instruction  set  of  the  Traffic  Controller.  A 
detailed  discussion  of  six  of  tne  procedures  contained  in 
the  Traffic  Controller  module  is  presented  below.  The 
remaining  tnree  procedures  (viz.,  TC_INIT,  CREATE_PRCCESS  , 
and  CREATE_KST)  were  described  in  chapter  tnree.  The  PLZ/ASM 
assembly  language  source  code  listings  for  tne  Traffic 
Controller  module  is  provided  in  Appendix  £. 
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1.   TC  Getwork 

Procedure  TC_GETWOF.K  provides  tne  mechanism  for  user 
process  scheduling".  The  input  parameters  to  TC_GSTWORK  are 
the  VP  ID  of  tne  virtual  processor  to  wnich  a  process  will 
be  scheduled  and  the  logical  CPU  number  to  wnich  the  virtual 
processor  telongs.  The  determination  of  which  process  to 
schedule  is  made  by  a  looping  mechanism  that  finds  the  first 
"ready"  process  on  the  ready  list  associated  with  the 
current  logical  CPU  number.  Processes  appear  in  the  ready 
list  by  order  of  priority.  This  looping-  mechanism  is 
required  as  both  "running"  and  "ready"  processes  are 
maintained  on  the  ready  list.  This  ready  list  structure  was 
cnosen  to  simplify  the  algorithm  provided  in  procedure 
TC_Advance.  If  a  ready  process  is  found,  its  state  is 
changed  to  "running"  and  its  process  IE  (viz.,  the  APT  entry 
number)  is  inserted  in  the  running  list  entry  associated 
with  the  current  virtual  processor.  Procedure  S'ji/aP_VLER  is 
then  invoiced  in  the  Inner  Traffic  Controller  to  effect  the 
actual  process  switch.  If  a  ready  process  was  not  found 
(viz.,  the  ready  list  was  empty  or  comprised  solely  of 
"running  processes"),  then  tne  running  list  entry  associated 
with  the  current  virtual  processor  is  marked  with  the 
constant  "ldie_Proc"  and  procedure  IDLE  is  invoked  in  tne 
Inner  Traffic  Controller. 
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2.      TC  Await 

The  primary  function  of  TC_AWAIT  is  the 
determination  of  whether  some  user  specified  event  has 
occurred.  If  the  event  nas  occured,  control  is  returned  to 
the  caller.  Otherwise,  the  process  is  blocked  and  another 
process  is  scneduled.  The  input  uarameters  to  TC_AWAIT  are  a 
pointer  to  a  segment  handle,  an  instance  (event  number),  and 
a  user  specified  eventcount  value.  TC_AWAIT  initially  locks 
the  Active  Process  Table  and  obtains  the  current  value  of 
tne  eventcount  in  question  by  calling  procedure 
MM_READ_Ev"EMTCCUNT.  The  determination  of  event  occurrence  is 
made  by  comparing  tne  user  specified  eventcount  value  with 
the  current  eventcount.  If  the  user  value  is  less  than  or 
equal  to  tne  current  eventcount,  tne  awaited  event  nas 
occurred  and  control  is  returned  to  the  caller.  Otherwise, 
tne  awaited  event  nas  not  yet  occurred  and  tne  process  must 
be  blocked. 

If  the  process  is  to  be  blocked,  procedure 
HTJNNINGJTP  is  invoked  to  ascertain  the  7?  ID  of  ta»  virtual 
processor  bound  to  the  process.  The  process'  IT  (viz  .  ,  APT 
entry  number)  is  then  read  from  the  running  list.  The  input 
parameters  to  TC_AWAIT  (viz..  Handle,  Instance,  and  Value) 
are  then  stored  in  the  Event  Data  portion  of  the  process' 
APT  entry.  Tne  process  is  removed  from  its  associated  ready 
list  by  redirecting  the  appropriate  linking  threads 
(pointers).  Once  removed  from  tne  ready  list,  tne  process  is 
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threaded  into  the  blocked  list   and   its   state   changed   to 
"blocked"  by  invocation  of  the  library  function  LiST_INSEET . 
Procedure   TCJ3-ETWORK   is   tnen   called   to  schedule  another 
process  for  the  current  virtual  processor. 
3.   TC  Advance 

The  primary  purpose  of  TC_ADVANCB  is  the 
broadcasting  of  some  event  occurrence.  Tnis  entails 
incrementing  the  eventcount  associated  with  the  event, 
awakening  all  processes  that  are  waiting  for  tne  event,  and 
insuring  proper  scheduling  order  by  venerating  any  necessary 
virtual  preempt  interrupts.  Tne  nign  level  design  algoritnm 
for  TC_ADVANCE  is  provided  in  figure  11.  The  input 
parameters  to  TC_AJ)VANCE  are  a  pointer  to  a  segment's  nandie 
and  an  instance  (event  number).  Initially,  TC_ADVANCE  locks 
tne  APT  to  prevent  tne  possibility  of  a  race  condition.  Tne 
eventcount  identified  by  the  input  parameters  is  then 
incremented  by  calling  ^M_ADVANCE.  MM_ADVANCS  returns  tne 
new  value  of  the  eventcount.  Once  the  eventcount  has  been 
advanced,  TC_ADVANCE  awakens  all  processes  awaiting  tnis 
event  occurrence.  This  is  accomplished  by  checking  all 
processes  tnat  are  currently  in  tne  blocked  list.  Tne 
process'  HANDLE  and  INSTANCE  entries  are  compared  with  the 
nandie  and  instance  identifying  tne  current  event.  If  tney 
are  the  same,  then  the  process  is  awaiting  some  occurrence 
of  tne  current  event.  In  sucn  a  case,  tne  process'  VALUE 
entry  in  the  APT  is  compared  with  the  current  value   of   the 
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TC_ADVANCE    Procedure  (HANDLE,  INSTANCE) 

Be^in 

!  Get  new  eventcount  ! 

COUNT  :=  MM_ADVANCE  (HANDLE,  INSTANCE) 

Call   WAIT_L0CK  (APT) 

!   Vaie  up  processes    ! 
PROCESS    :=    SLOCKED_LIST_HEAD 

Do   wnile   not;    end   of   i3LOCKED_IIST 
If    (PROCESS. HANDLE   =   HANDLE)    and 

(PROCESS. INSTANCE  =  INSTANCE)  and 
(PROCESS. COUNT  <=  COUNT) 
tnen 

Call      LIST_INSERT(READX    LIST) 
end   if 

PROCESS    :=  PROCESS. NEXT_PROCESS 
end  do 

!  Cnecfc  all  ready  lists  for  preempts  ! 
LOGICAL_CPU_NO  :=  1 

Do  wnile  LOGICAL_CPU_NO  <=  #NR_CPU 
!  Initialize  oreempt  vector  ! 
VP_ID  :=  FIRST_VP(LOGICAL_CPU_NO) 

Do  for  LOOP  :=  1  to  NR_VP( LOGICAL_CFU  NO 
RUNNING_LIST[VP_ID] .PREEMPT  :=  #TRUE 

VP_ID  :=  VP_ID  +  1 
end  do 

!  Find  preempt  candidates  ! 
CANDIDATES  :=  0 

PROCESS  :=  READV  LIST  HEAD(LOGICAL  CPU  NO) 


Figure  11.   TC_ADVANCE  Algoritnrr 
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VP_ID    :=    EIRST_VP(L0GICA1_CPU_N0) 

Do    (for    CYCLE   =    1    to    NR   7?(LOGICAL_CPU_N0 )    and 
not    end   of   REAM   LIST  (LOGICAL   CPU   NO) 
If      PROCESS    =    ^RUNNING 

tnen 

RUNNING_LISTIVP_IDJ .PREEMPT  :=  #FALS2 
else 

CANDIDATES  :=  CANDIDATES  +  1 
end  if 

7P_ID  :=  VP_ID  +  1 
PROCESS  :=  PROCESS. NEXT_PROCESS 
end  do 

!  Preempt  appropriate  candidates  ! 
VT>_ID  :=  EIRST_V?(LOGICAL_CPU_NO) 

To  for  CHECK  :=  1  to  NR_VP (LOGICAL_CPU  NO ) 
If  (RUNNING_LIST[VP_IDJ  .PREEMPT  =  #TRUE)  and 
(CANDIDATES  >  0) 
tnen 
Call   SET_PREEMPT(VP_ID) 

CANDIDATES  :=  CANDIDATES  -  1 
end  if 

vp_ID  :=  VP_ID  +  1 
end  do 

IOGICAL_CPU_NO  :=  LOGICAI_CPU_NO  +  l 
end  do 

Call   UNLOCK(APT) 

Return 

End  TC  ADVANCE 


figure  11.   TC  ADVANCE  Aigoritnm   (Continued) 


88 


eventcount.  If  tne  process'  VALUE  is  less  tnan  or  equal  to 
the  current  eventcount  value,  tne  awaited  event  nas  occurred 
and  tne  process  is  removed  from  tne  blocked  list  and 
threaded  into  the  appropriate  ready  list  by  tne  library 
function  LIST_INSERT. 

Once  the  blocked  list  has  been  checked,  it  is 
necessary  to  reevaluate  eacn  ready  list  to  insure  that  the 
nighest  priority  processes  are  running.  It  is  relatively 
simple  to  determine  if  a  virtual  preempt  interrupt  is 
necessary,  however,  it  is  considerably  more  difficult  to 
determine  which  virtual  processor  should  receive  the  virtual 
preempt.  To  assist  in  tnis  evaluation,  a  "count"  variable 
(number  of  preempts  needed)  is  zeroed  and  a  preempt  vector 
is  created  on  the  Kernel  stack  with  an  entry  for  every 
virtual  processor  associated  with  the  logical  CPU  being 
evaluated.  Initially,  every  entry  in  tne  preempt  vector  is 
marked  "true"  indicating  tnat  its  associated  virtual 
processor  is  a  candidate  for  preemption.  Once  the  preempt 
vector  is  initialized,  tne  first  "n"  processes  on  the  ready 
list  (where  n  equals  the  number  of  VP's  associated  with  the 
current  logical  CPU)  are  checked  for  a  determination  of 
their  state.  If  a  process  is  found  to  be  "running'"  then  it 
should  not  be  preempted  as  processes  appear  in  tne  ready 
list  in  order  of  priority.  When  a  running  process  is  found, 
its  associated  entry  in  tne  preempt  vector  is  marked 
"false."   If   a  process  is  encountered  in  tne  "ready"  state 
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then  it  should  be  running  and  the  count  variable  is 
incremented.  Wnen  tne  first  "n"  processes  nave  been  cnecfced 
or  when  we  reach  the  end  of  the  current  ready  list 
(wnicnever  comes  first),  the  entries  in  tne  preempt  vector 
are  "popped"  from  the  stacir.  If  an  entry  from  the  preempt 
vector  is  found  to  be  "true",  this  indicates  that  its 
associated  virtual  processor  is  a  candidate  for  preemption 
since  it  is  either  hound  to  a  lower  priority  process,  or  it 
is  "idle."  In  such  a  case,  tne  "count"  variable  is  evaluated 
to  determine  if  the  virtual  processor  associated  with  tne 
vector  entry  should  be  preempted.  If  the  count  exceeds  zero, 
a  virtual  preempt  interrupt  is  sent  to  the  V?  and  the  count 
is  decremented.  Otherwise,  no  preempt  is  sent  as  tnere  is  no 
Higher  priority  process  awaiting  scheduling. 

This  preemption  algorithm  is  completed  for  every 
ready  list  in  tne  Active  Process  Table.  Once  all  ready  lists 
nave  been  evaluated,  tne  APT  is  unlocked  ana  control  is 
returned  to  the  caller.  It  is  noted  that  it  is  not  necessary 
to  invoke  TC_GETWORK  before  exiting  ADVANCE.  If  tne  current 
V?  requires  rescheduling,  it  will  have  received  a  virtual 
preempt  interrupt  from  the  preemption  algorithm.  If  this  has 
occurred,  the  VP  will  be  rescheduled  wnen  its  running 
process  attempts  to  leave  tne  Kernel  domain  ana  the  virtual 
preempt  interrupts  are  unmasJced. 
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4.  Virtual  Preempt  Handier 

VIRTUAL  J>REEMPT_HANDLER  is  the  interrupt  nandler  for 
virtual  preempt  interrupts.  The  entry  address  of 
VIRTUAL_PREEMPT_HANDLER  is  maintained  in  the  virtual 
interrupt  vector  located  in  the  Inner  Traffic  Controller. 
Once  invoked,  the  handler  locks  the  Active  Process  Table  and 
determines  which  virtual  processor  is  being  preempted  hy 
calling  RUNNINGJTP.  The  process  running  on  the  preempted  VP 
is  then  set  to  the  "ready"  state  and  TC_GETW0R5  is  invoked 
to  reschedule  tne  virtual  processor.  When  TC_GETWORK  returns 
to  VIRTUAL_PREEMPT_fiANDLER,  the  APT  is  unlocked  and  a 
virtual  interrupt  return  is  executed.  This  return  is  simply 
a  jump  to  the  point  in  the  hardware  preempt  handler  where 
the  virtual  interrupts  are  unmasked.  This  effects  a  virtual 
interrupt  return  instruction. 

5.  Remaining  Procedures 

The  remaining  two  procedures  in  tne  Traffic 
Controller  module  represent  the  extended  instructions: 
PROCESS_CLASS  and  GET_DBR_NUMBER .  Both  procedures  lock  the 
Active  Process  Table  and  call  RUNNING_VP  to  determine  which 
virtual  processor  is  executing  the  current  process.  The 
process  ID  (viz.,  APT  entry  Number)  is  then  extracted  from 
the  running  list.  PROCESS_CLASS  reads  and  returns  the 
current  process'  security  access  classification  from  the 
APT.  GET_DBR_NUMBER  reads  and  returns  tne  current  process' 
DBR  handle.   It   should   be   noted   that  in  general  the  BBR 
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number  provided  by  procedure  GET_DBR_NUMBER  is  only  valid 
while  the  APT  is  locked.  Particularly,  in  the  current  SASS 
implementation,  the  Segment  Manager  invokes  GET_DBP_NUMBER 
and  then  passes  the  obtained  DBF.  number  to  the  Distributed 
Memory  Manager  for  utilization  at  that  level.  In  a  more 
general  situation,  the  process  associated  with  the  DBR 
number  may  nave  been  unloaded  before  the  DBR  number  was 
utilized,  thus  making  it  invalid.  This  problem  does  not 
arise  in  SASS  as  ail  processes  remain  loaded  for  the  life  of 
the  system. 

C.   DISTRIBUTED  MEMORY  MANAGER  MODULE 

The  Distributed  Memory  Manager  module  provides  an 
interface  between  the  Segment  Manager  and  the  Memory  Manager 
process,  manipulates  event  data  in  the  Global  Active  Segment 
Table  (G_AST),  and  dynamically  allocates  available  memory.  A 
detailed  description  of  the  Distributed  Memory  Manager 
interface  to  the  Memory  Manager  process  was  presented  by 
Wells  [6].  The  remaining  extended  instruction  set  is 
discussed  in  detail  below.  The  complete  P1Z/ASM  source 
listings  for  the  Distributed  Memory  Manager  module  is 
provided  in  Appendix  C. 

1.   MM  Read  Eventcount 

MM_READ_EVENTCOUNT  is  invoked  by  the  Event  Manager 
and  tne  Traffic  Controller  to  obtain  the  current  value  of 
the   eventcount   associated  with  a   particular   event.    The    input 
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parameters  to  this  procedure  are  a  segment  nandle  pointer 
and  an  instance  (event  Number),  which  together  uniquely 
identify 'a  particular  event. 

The  G_AST  is  locked  and  the  entry  offset  of  the 
segment  into  the  G_AST  is  obtained  from  the  segment's 
handle.  The  instance  parameter  is  then  validated  to 
determine  which  eventcount  is  to  be  read.  If  an  invalid 
instance  is  specified,  control  is  returned  to  the  caller 
specifying  an  error  condition.  Otherwise,  the  current  value 
of  the  specified  eventcount  is  read.  The  G_AST  is  then 
unlocked,  and  the  current  eventcount  value  is  returned  to 
the  caller. 

2.   MM  Advance 

MM_ADVANCE  is  invoiced  by  the  Traffic  Controller  to 
reflect  the  occurrence  of  some  event.  The  input  parameters 
to  MM_ADVANCE  are  a  pointer  to  a  segment's  handle  and  a 
particular  instance  (event  number). 

The  Global  Active  Segment  Table  is  locxed  to  prevent 
a  race  condition,  and  the  offset  of  the  segment's  entry  into 
the  G_AST  is  obtained  from  the  segment  handle.  The  instance 
parameter  is  then  validated  to  determine  which  eventcount  is 
to  be  advanced.  If  an  invalid  instance  is  specified,  an 
error  condition  is  returned  to  the  caller  and  no  data 
entries  are  affected.  If  the  instance  value  is  valid,  the 
appropriate  eventcount  is  incremented,  and  its  new  value  is 
returned. 
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3.  MM  Ticfcet 

MM_TICOT  is  invoked  by  the  Event  Manager  to  obtain 
tne  current  value  of  tne  sequencer  associated  with  a 
specified  segment.  Tne  input  parameter  to  MM_TICKET  is  a 
pointer  to  a  segment's  handle. 

Initially,  MMJTICKET  locks  tne  Global  Active  Segment 
Table  to  prevent  a  race  condition.  Next  the  offset  of  the 
segment's  entry  into  the  G_AST  is  obtained  from  tne  segment 
handle.  The  current  value  of  the  sequencer  for  the  specified 
segment  is  then  read  and  saved  as  a  return  parameter  to  the 
caller.  The  sequencer  value  is  then  incremented  in 
anticipation  of  tne  next  ticket  request.  Once  this  is 
complete,  the  G_AST  is  unlocked  and  control  is  returned  to 
the  caller. 

4.  MM   Allocate 

The  MM_ALLOCATE  procedure  provided  in  this 
implementation  is  a  stub  of  tne  MM_A1L0C&TE  described  in  tne 
Memory  Manager   design   of  Moore   and   Gary    [4]  . 

The  primary  function  of  MM_AILOCATE  is  t.ne  dynamic 
allocation  of  fixed  size  biocics  of  available  memory  space. 
It  is  invoked  in  the  current  implementation  by  tne 
initialization  routines  in  B00TSTRAP_L0AJ3ER  and  TC_INI?  for 
tne  allocation  of  memory  space  used  in  tne  creation  of  tne 
Kernel  domain  and  Supervisor  domain  stack  segments  and  the 
creation  of  the  Known  Segment  Tables  for  user  processes. 
Dynamic     reallocation   of   previously  used  memory   space    (viz., 

94 


garbage  collection)  is  not  provided  by  tne  MM_AIIOCATE  stub 
in  tnis  implementation.  All  memory  allocation  required  in 
tnis  implementation  is  for  segments  supporting  system 
processes  that  remain  active,  and  thus  allocated,  for  tne 
entire  life  of  tne  system.  Memory  is  allocated  in  blocks  of 
256  (decimal)  bytes  of  processor  local  memory  (on-board 
P.AM).  In  tnis  stub  allocatable  memory  is  declared  at  compile 
time  by  a  data  structure  (MEM_POOL)  tnat  is  accessible  only 
by  MM_ALLOCATE. 

Tne  input  parameter  to  MM_AILOCATE  is  tne  number  of 
blocks  of  requested  memory.  Tnis  parameter  is  converted  from 
a  block  size  to  tne  actual  number  of  bytes  requested.  Tnis 
computation  is  made  simple  since  memory  is  allocated  in 
powers  of  two.  Tne  byte  size  is  obtained  by  logically 
shifting  left  the  input  parameter  ei,?nt  times,  where  ei^ht 
is  tne  power  of  two  desired  (viz.,  256).  Once  tne  size  of 
the  requested  memory  is  computed,  it  is  necessary  to 
determine  tne  starting  address  of  tne  memory  biock(s)  to  be 
allocated.  To  assist  in  this  computation,  a  variable 
(NEXT_BL0C£)  is  used  to  keep  track  of  tne  next  available 
block  of  memory  in  MEM_P00L.  NEXT_BLOCK,  which  is 
initialized  as  zero,  provides  tne  offset  into  tne  memory 
being  allocated.  Once  the  starting  address  is  obtained,  the 
physical  size  of  the  memory  allocated  is  added  to  NEXT_2ICCK 
so  that  the  next  request  for  memory  allocation  will  begin  at 
the  next  free  byte  of  memory  in  MEY_POOL.  This  new  value   of 
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NEXT_BLOCK   is   saved  and  tne  starting  address  of  tne  memory 
for  tnis  request  is  returned  to  tne  caller. 

D.   GATE  KEEPER  MODULES 

The  SASS  Gate  Keeper  provides  the  logical  boundary 
between  tne  Supervisor  and  tne  Kernel  and  isolates  tne 
Kernel  from  the  system  users,  thus  ma  King-  it  tamperproof . 
Tnis  is  accomplished  by  means  of  tne  nardware  system/normal 
mode  and  the  software  ring-crossing  mechanism  provided  by 
the  Gate  Keeper.  Tne  Gate  Keeper  is  comprised  of  two 
separate  modules:  l)  tne  USER_GATE  module,  and  2)  tne 
KERNEL_GATE_KEEPER  module.  Tnese  modules  are  disjoint,  with 
the  USER_GATE  module  residing  in  the  Supervisor  domain  and 
the  KERNEL_GAT£_KEEPER  module  residing  in  tne  Kernel  domain. 
It  is  important  to  note  tnat  the  USER_GATE  is  a  separately 
linked  component  in  the  Supervisor  domain  and  is  not  linked 
to  the  Kernel.  The  only  tning  in  common  between  tnese  two 
modules  is  a  set  of  constants  identifying  tne  valid  extended 
instruction  set  which  tne  Kernel  provides  to  the  users. 

The  Gate  Keeper  modules  presented  in  tnis  implenemtation 
are  only  stubs  as  they  do  not  provide  all  of  the  functions 
required  of  the  Gate  Keeper.  However,  the  only  tas*  not 
provided  in  this  implementation  is  the  validation  of 
parameters  passed  from  the  Supervisor  to  the  Kernel.  A 
detailed  description  of  this  parameter  validation  design  is 
provided    by   Coleman    [3]  .   In   the   process   management 
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demonstration,  tne  Supervisor  stubs  are  written  in  PLZ/ASM 
with  all  parameters  passed  by  CPU  registers.  A  detailed 
description  of  the  Gate  Keeper  modules  and  tne  nature  cf 
tfteir  interfaces  is  presented  below.  Tne  PLZ/ASM  source 
listings  for  tne  two  Gate  Keeper  modules  are  provided  in 
Appendix  E. 

1.  User  Gate  Module 

Tne  USER_GATE  module  provides  tne  interface 
structure  between  tne  user  processes  in  tne  Supervisor 
domain  and  the  Kernel.  Tne  USER_GATS  is  comprised  of  ten 
procedures  (viz.t  entry  points)  tnat  correlate  on  a  one  to 
one  basis  witn  the  ten  "user  visible"  extended  instructions 
(listed  in  figure  6)  provided  by  the  Kernel.  The  only  action 
performed  by  each  of  these  procedures  is  the  execution  of 
the  "system  call"  instruction  (SO  with  a  constant  value, 
identifying  the  particular  extended  instruction  inve&ed,  as 
the  source  operand. 

The  SC  instruction  is  a  system  trap  tnat  forces  tne 
hardware  into  the  system  mode  (Kernel  domain)  and  loads 
register  15  with  tne  system  stacx  pointer  (Kernel  domain 
stack).  The  current  instruction  counter  value  (IC)  is  pushed 
onto  tne  Kernel  stacit  along  witn  tne  current  CPU  flag 
control  word  (PCW).  In  addition,  the  system  trap  instruction 
is  pushed  onto  tne  Kernel  stack:  with  tne  upper  byte 
representing  the  SC  instruction  and  the  lower  byte 
representing   the  SC  instruction's  source  operand  (viz.,  tne 
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Kernel  extended  instruction  code).  Togetner,  these 
operations  form  an  interrupt  return  (IRET)  frame  as 
illustrated  in  figure  9.  Once  tnis  is  complete,  tne  ECW  is 
loaded  witn  tne  3?CW  value  found  in  tne  System  Call  frame  of 
the  Program  Status  Area  (viz.,  tne  hardware  "interrupt 
vector").  Tne  structure  of  tne  Program  Status  Area  is 
illustrated  in  figure  12,  Tne  instruction  counter  is  then 
loaded  witn  the  address  of  the  SC  instruction  trap  nandier. 
This  value  is  also  located  in  the  SC  frame  of  the  Program 
Status  Area. 

2.   Kernel  Gate  Keeper  Module 

The  system  trap  nandier  for  the  System  Call 
instruction  is  the  KERNEL_GAT£_KEEPER .  The  address  of  the 
KERNEL_GATE_KEEPER  and  the  Kernel  FCW  value  are  placed  in 
the  System  Call  frame  of  tne  Program  Status  Area  by  the 
BOOTSTRAP_LOADER  module  during  initialization.  The 
ORNEL_GATE_KEEPER  fetches  the  extended  instruction  code 
from  the  trap  instruction  entry  in  the  IRET  frame  on  the 
Kernel  stack.  This  value  is  then  decoded  by  a  "case" 
statement  to  determine  which  extended  instruction  is  to  be 
executed.  If  the  extended  instruction  cod*3  is  valid,  the 
appropriate  Kernel  procedure  is  invoiced.  Otnerwise,  an  error 
condition  is  set  and  no  Kernel  procedures  are  not  invoked. 
Once  control  returns  to  tne  KERNEI_GATE_KEEPER ,  tne  CPU 
registers  and  normal  stack  pointer  (NSP)  value  are  pushed 
onto  tne  Kernel  stack  in   preparation   for   return   to   the 
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Figure   12.      Program   Status   Area 
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Supervisor  domain.  It  is  noted  that  this  operation  would 
normally  occur  immediately  upon  entry  into  tne 
KERNEL_GATE_KEEPER .  In  this  implementation,  however, 
parameter  validation  is  not  accomplished  and  the  CPU 
registers  are  used  to  pass  parameters  to  and  from  the  Kernel 
only  for  use  by  the  process  management  demonstration.  In  an 
actual  SASS  environment,  all  parameters  would  be  passed  in  a 
separate  argument  list  and  the  CPU  registers  would  appear 
exactly  the  same  upon  leaving  the  Kernel  as  they  did  upon 
entering  the  Kernel.  This  is  important  to  insure  that  no 
data  or  information  is  leaded  from  the  Kernel  by  means  of 
the  CPU  registers. 

Control  is  returned  to  tne  Supervisor  by  means  of  the 
return  mechanism  in  the  hardware  preempt  handier.  This 
mechanism  is  utilized  to  preclude  tne  necessity  of  building 
a  separate  mechanism  for  the  KERNEI_GAT2_KEEPER  that  would 
actually  perform  the  very  same  function.  To  accomplisn  tnis, 
the  KERNEL_GATE_KEEPER  executes  an  unconditional  jump  to  the 
PR£EMPT_RET  label  in  PHYS_PREEMPT_HANDLER .  Tnis  "jump"  to 
the  hardware  preempt  handler  represents  a  "virtual  IRET" 
instruction  providing  the  same  function  as  tne  virtual 
interrupt  return  described  in  the  discussion  of  tne  virtual 
preempt  handler.  At  tnis  point,  tne  virtual  preempt 
interrupts  are  unmaslced,  the  normal  staci  pointer  and  CPU 
registers  are  restored  from  the  stacir,  and  control  is 
returned  to  the  Supervisor  by  execution  of  the  IRET 
instruction. 
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E.   SUMMARY 

The  implementation  of  process  management  functions  for 
tne  SASS  Has  been  presented  in  tnis  cnapter.  Tne 
implementation  was  discussed  in  terms  of  the  Event  Manager, 
Traffic  Controller,  Distributed  Memory  Manager,  and  Gate 
Keeper  modules. 

Cnapter  V  will  present  tne  conclusions  drawn  from  tnis 
wort  and  suggestions  for  future  wori  derived  from  tnis 
thesis  . 
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V.   CONCLUSION 

The  implementation  of  process  management  for  the 
security  Kernel  of  a  secure  arcnival  storage  system  nas  ceen 
presented.  The  process  management  functions  presented 
provide  a  logical  and  efficient  means  of  process  creation, 
control,  and  scheduling.  In  addition,  a  simple  but  effective 
mechanism  for  inter-process  communication,  cased  on  tne 
eventcount  and  sequencer  primitives,  was  created.  Work  was 
also  completed  in  tne  area  of  Kernel  database  initialization 
and  a  Gate  Keeper  stub  to  allow  for  dual  domain  operation. 

The  design  for  tnis  implementation  was  based  on  tne 
Zilog  Z8001  sixteen  bit  segmented  microprocessor  [17J  used 
in  conjunction  witn  tne  Zilog  Z8010  memory  Management  Unit 
[18].  The  actual  implementation  of  process  management  for 
the  SASS  was  conducted  on  the  Advanced  Micro  Computers 
Am9b/4116  MonoBoara  Computer  [19 )  featuring  tne  AmZS002 
sixteen  bit  non-segmented  microprocessor.  Segmentation 
nardware  was  simulated  by  a  software  Memory  Management  Unit 
Image. 

This  implementation  was  effected  specifically  to  support 
the  Secure  Archival  Storage  System  (SASS)  (.21J  .  However,  tne 
implementation  is  based  on  a  family  of  Operating  Systems  [lj 
designed  with  a  primary  goal  of  providing  multilevel 
information  security.  Tne  loop  free  modular  design  utilized 
in   this   implementation   easily   facilitates   any   required 
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expansion   or  modification   for   otner   family  members.  In 
addition,    tnis    implementation    fully    supports    a 

multiprocessor  design.    Wnile    tne    process   management 

implementation  appears  to  perform  correctly,  it  Has  not  been 

subjected  to  a  formal  test  plan.  Such  a  test  plan  snould   be 

developed   and  implemented   before   Kernel   verification  is 
begun. 

A.   FOLLOW  ON  WORK 

Tnere  are  several  possitie  areas  in  tne  SASS  design  tnat 
would  be  immediately  suitable  for  continued  research.  In  the 
area  of  nardware,  tnis  includes,  tne  establishment  of  a 
multiprocessor  environment,  hardware  initialization,  and 
interfacing  to  tne  host  computers  and  secondary  storage. 
Further  wort  in  tne  Kernel  includes  the  actual 
implementation  of  the  memory  manager  process,  and  the 
refinement  of  tne  Gate  Keeper  and  Kernel  intiali zat ion 
structures.  The  implementation  of  the  Supervisor  has  not 
been  addressed  to  date.  Its  areas  of  research  include  the 
implementation  of  the  File  Manager  and  Input/Cutput 
processes,  and  the  final  design  and  implementation  of  tne 
SASS-Hosts  protocols. 

Otner  areas  tnat  could  also  prove  interesting  in 
relation  to  the  SASS  include  the  implementation  of  dynamic 
memory  management,  the  support  of  multilevel  nosts,  dynamic 
process  creation  and  deletion,  and  the  provision  of 
constructive  worK  to  be  performed  by  tne  Idle  process. 
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APPENDIX   A    -    EVENT    MANAGER    LISTINGS 


Z8000ASM   2.02 

IOC     OBJ  COLE     STMT  SOURCE 

STATEME 

$LISTON  $TTY 

EVENT_MGR        MODULE 

CONSTANT 

T"PTJE 

=  1 

FALSE 

-=  0 

READ  ACCESS 

'-  1 

WRITE  ACCESS 

=  0 

SUCCEEDED 

=  2 

SEGMENT  NOT  KNOWN 

:=  28 

ACCESS  CLASS  NOT  EC 

=  33 

ACCESS  CLASS  NOT  GE 

=  41 

KST  SEG  NO 

:=  2 

NR  OF  KSEGS 

:=  10 

MAX  NO  KST  ENTRIES 

=  54 

NOT  KNOWN 

:=  %Y7 

TVPE 

H_ARRAI 

ARRAY [3 

WORDJ 

KST  REC     RECORD 

[W  HANDLE 

H  ARRAY 

SIZE 

WORD 

ACCESS  MODE 

BYTE 

IN  CORE 

BYTE 

CLASS 

LONG 

M  SEG  NO 

SHORT  INTEGER 

ENTRY  NUMBE' 
J 

R  SHORT 

INTEGER 

EXTERNAL 

MM  TICKET 

PROCEDURE 

MM  READ  EVENTCOUNT 

PROCEDURE 

TC~ADVANCE 

PROCEDURE 

TC  AWAIT 

PROCEDURE 

PROCESS  CLASS 

PROCEDUR3 

CLASS  EO* 

PROCEDURE 

CLASS  GE 

PROCEDURE 

ITC  GET  SEG  PTR 

PROCEDURE 
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INTERNAL 

$SECTION  EM_KST_DCL 

!  NOTE:  THIS  SECTION  IS  AN  "OVERLAY" 
OR  "FRAME"  USED  TO  DEFINE  THE 
FORMAT  OF  THE  KST.   NO  STORAGE  IS 
ASSIGNED  EUT  RATHER  THE  KST  IS 
STORED  IN  A  SEPARATELY  OBTAINED 

AREA.  (A  SEGMENT  SET  ASIDE  FOR  IT)! 

$ABS    0 
mm  KST        ARRAY  [MAX_NO_KST_ENTPIES    KST_RECJ 
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GLOBAL 
SSECTION 


EM    GLB    PROC 


0000 


READ  PROCEDURE 

*  READS    SPECIFIED    EVENTCOUNT    * 

*  AND    RETURNS    IT'S    VALUE    TO      * 

*  THE    CALLER  * 

*  PARAMETERS:  * 

*  Rl:    SEGMENT   #  * 

*  R2:    INSTANCE  - 

-^  ;,c  ;,;;,;;,;;,;  ^;  ;,;  ^  ^c  ;,;;,;  ^i  ;,;„,;  ;,i  j(;  ,,;  ;(£  ;,;  »»*3i5  ;,:  ^,;  ^;  £»;  i,i  JX  5,c  ;,i 

*  RETURNS :  * 

*  R0:    SUCCESS    CODE  * 

*  RR4:    EVENTCOUNT  v 


0000   93F2 


ENTRV 
!    SAVE    INSTANCE    ! 
PUSH        0R15,    R2 


0002    2102 
0004    0001 

000b    5F00 
0008    0000' 


000A  0B00 
000C    0002 

000E  5E0E 
0010    001C' 

0012  97F2 
0014  5F00 
0016    0000* 


!      READ      ACCESS    REQUIRED    ! 
LD  R2,    #READ_ACCESS 

!    GET    SEG    HANDLE   &    VERIFY    ACCESS    ! 
CALL         CONVERT    AND   VERIFY    !R1:SEG    # 


R2:REO.    ACCESS 
RETURNS: 
R0:SUCCESS    CODE 
Rl  .'HANDLE    PTR  ! 


C^ 


R0,    #SUCCEEDED 


IF    EO    !ACCESS    PERMITTED! 
THEN       !READ    EVENTCOUNT! 

IRESTORE    INSTANCE! 

POP      R2,    PR15 

CALL    MM    READ    EVENTCOUNT    !Rl:HPTR 


R2:INSTANCE 
RETURNS: 
R0:SUCCESS    CODE 
RR4:EVENTCOUNT! 


0018    5E08 

ELSE       !RESTORE    SP! 

001A    001E' 

001C   97F2 

POP      R2,    GR15 

FI 

001E   9E08 

RET 

0020 

END   READ 
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4?026? 


TICKET  PROCEDURE 

I  rfTfrf  ijiif.zf.ij.7f.-xf.7s. ;?. if  if  7f  if.  v  v^^W?-"^'1;'?=?W  V  *P 

*  RETURNS    CURRENT    VALUE    OF  * 

*  TICKET    TO    CALLER   AND    INCRE-   * 

*  MENTS    SEQUENCER    FOR    NEXT  * 

*  TICKET   OPERATION  * 

^.7fif^7fl£7f*f3flf%C7f,3f^l£7f.lf,&Zf%L7f7fi7flF,XfXf7filf,3fl,llf 

*  PARAMETERS:  * 

*  Rl:    SEGMENT    #  * 

7fJf7f7f7fXf7f7f7f7f3f^l^lf7f\il^rf7fXf7^7fltl7f-XfXf7flflf.7flf 

*  RETURNS:  * 

*  R0:    SUCCESS    CODE  * 

*  RR4:    TICKET    VALUE  * 


0020    2102 

0022  0000 

0024    5F00 
0026    0000' 


0028    0E00 
002A    0002 

002C    5E0E 
002E    0038' 
0030    5F00 
0032    0000* 


0034    2100 
0036    0002 

0038   9E08 
003A 


ENTRI 
!    GET    SEC-    HANDLE    6,   VERIFT    ACCESS     ! 
!    "WRITE"    ACCESS    REQUIRED    ! 
LD  R2,    *WRITE_ACCESS 

CALL      CONVERT    AND    VERIFY    !R1:SEG    # 


R2:ACCESS    REC 
RETURNS: 
R0:SUCCESS    CODE 
Rl rHANELE    PTR! 


CP 


R0,    ^SUCCEEDED 


IF   EO    IACCESS    PERMITTED! 
THEN       !    GET    TICKET    ! 

CALL      MM_TICKET    !Rl:EANDLE    PTR 

RETURNS  : 
RR4:TICKET! 

!    RSTORE    SUCCESS    CODE    ! 

LD  R0,    ^SUCCEEDED 

FI 
RET 
END    TICKET 
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003A 


* 


AWAIT  PROCEDURE 

*  CURRENT    EVENTCOUNT    VALUE    IS 

*  COMPARED    TO    USER    SPECIFIED 

*  VALUE.    IF    USER    VALUE    IS 

*  GREATER   THAN    CURRENT    EVENT- 

*  COUNT  VALUE  THEN  PROCESS  IS 
"BLOCKED"  UNTIL  THE  DESIRED 
EVENT   OCCURS  . 

ifi  »,*  J|»  tofi  2f*  SgC  «f*  ^|i  i|i  5j£  2yS  3|S  5|%  »,5  »,«  *,i  *|C  *J%  *|*  i,»  »|»  *^»  *(»  ii*  »|*  *,*  *(*  *|»  3^5    »,*  -,* 

*  PARAMETERS:  * 

*  Rl :    SEGMENT   #  * 

*  R2:    INSTANCE    (EVENT    #)  - 

*  RR4:    SPECIFIED   VALUE  * 

*  RETURNS:  * 

*  Re:    SUCCESS    CODE  * 


003A   91F4 

003C   93F2 

003E    2102 
0040    0001 

0042   5F00 
0044    0000 


0046  0B00 
0048    0002 

004A  5E0E 
004C    005A' 

004E   97F2 

0050  95F4 
0052  5F00 
0054    0000* 


ENTRY 
!    SAVE    DESIRED    EVENTCOUNT    VALUE    ! 
PUSHL      0P.15,    RR4 
!    SAVE    INSTANCE    ! 
PUSH         0R15,    R2 
!    "READ"    ACCESS    REQUIRED    ! 
LD  R2,    #READ_ACCESS 

!    GET    SEG   HANDLE   S.    VERIFY    ACCESS    ! 
CALL         CONVERT    AND   VERIFY    !R1:SEG    # 


CP 


R0,    #SUCCEEDED 


R2:ACCESS    REQ 
RETURNS: 
R0:SUCCESS    CODE 
Rl:HANELE   FTR  ! 


IF   EQ    !    ACCESS    PERMITTED    ! 
TEEN    !    AWAIT    EVENT    OCCURRENCE    ! 

!    RESTORE    INSTANCE    ! 

POP      R2,    PR15 

!    RESTORE    SPECIFIED    VALUE    ! 

POPL   RR4,    GRliD 

CALL    TC_AWAIT    !R1:HANDLE   PTR 

R2:INSTANCE 
RR4: VALUE 
RETURNS: 
R0:SUCCESS    CODE! 
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0056  5E08  ELSE  .'RESTORE  STACK! 
0058  005E' 

005A  95F4  POPL   ?.R4,  (?R15 

005C  97E2  POP    R2,  GR15 

FI 

005E  9E08  RET 

0060  END  AWAIT 
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0060 


* 

9 


ADVANCE  ?P 

*  SIGNALS    THE    OCCURRENCE 

*  SOME    EVENT.       EVENTCOUN 

-  INCREMENTED    AND    THE    TR 
CONTROLLER    LS    INVOKED 
AWAKEN    ANT    PPOCESS    AWA 

-  THE    OCCURRENCE. 

— j*  »t*  ^S  Jj*^f*  J|K  J|-»  <-|C  J|*  *i(t  Jjf»  +fi  Wfi  *fi  ^p  ^^  »|»  #|%  *r*  >»•  Jj»  *p  *ip  *^ 

*  PARAMETERS: 

-  El:    SEGMENT    # 

*  R2:    INSTANCE    (EVENT    # 

*  RETURNS: 

*  R0:    SUCCESS    CODE 


OCEDURE 

yyiyyyy  sjs 

OF 

* 

T    IS 

* 

AFFIC 

>? 

TO 

* 

ITING 

=? 

* 

******* 

^ 

* 

) 

* 

******* 

* 

* 

0060   93F2 


ENTRY 

!    SAVE    INSTANCE    ! 
PUSH      0R15,    R2 


0062  2102 
0064  0000 
0066  3F00 
0068    0000' 


006A   0B00 
006C    0002 

006E    5E0E 
0070    007C' 

0072   97F2 


!    GET    SEG    HANDLE   &    VERIFY    ACCESS     ! 
!    "WRITE"    ACCESS    REQUIRED    ! 
LD  R2,    #WRITE_ACCESS 

CALL      CONVERT    AND   VERIFY    !R1:SEG    # 


R2:ACCESS    REG 

RETURNS: 
R0:SUCCESS    CODS 
Rl  : HANDLE    PTR! 


CP 


R0,    ^SUCCEEDED 


IF    EO    !    ACCESS    PERMITTEE    ! 
THEN    !    ADVANCED    EVENTCOUNT    ! 

!    RESTORE    INSTANCE    ! 
POP         R2t    GRlb 


0074    bF00 
0076    0000* 


0078  5E08 

007A  007E' 

007C  97F2 

007E  9E08 
0080 


CALL      TC_ADVANCE    !R1  .'HANDLE    PTR 

R2:  INSTANCE 
RETURNS : 

R0:SUCCESS    CODE! 
ELSE    JRESTORE    STACK! 

POP         R2,    0Rlb~ 
FI 
RET 
END    ADVANCE 
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0000 


INTERNAL 

SSECTION    EM_INT_PROC 

CONVERT    ANT    VERIFY 


PROCEETJRE 


I    *(£  -i*  *»5  ^|*  »,4  2^C  J,;  *^i  ^i  J jC  J,»  *,»  3|*  *,»  •»»  JjjJ  *»»  »i*  J,»  *»»  *,%  J,*  «|«  »,*  *j»  JJC  i,»  S|C  »|t  ;,£  »,»  jf*  2,1  £,i  J,»  3|C  3,C  »,*  5|* 

*  CONVERTS  SEGMENT  NUMEER  TO  KST  INDEX* 

*  AND  EXTRACTS  SEGMENT'S  HANDLE  FRO*   * 
v  KST.  IE  SUCCESSFUL,  THEN  ACCESS      - 

*  CLASS  OF  SUBJECT  IS  CHECKED  AGAINST  * 

*  ACCESS  CLASS  OF  OBJECT  TO  INSURE     * 

*  THAT  ACCESS  IS  PERMITTED.  v 

s*  ace  sp  a*  sje  age  sp  )gc  J*  *s  XT.  act  *  *  *  »*  *  »*  n*  ^  V  a*  S)t  =P  f  **  *?:  **  a*  3*  V  *«c  *  **  V  ^  **  W  V 

*  PARAMETERS:  * 

*  Rl:  SEGMENT  NUMBER  * 

*  R2:  ACCESS  REQUESTED  * 

^t  age  sp  v  agi  age  age  a?  age  19c  age  ac<  qc  age  jjc  jjc  age  jje  age  w  age  age  act  9?  ajs  age  3^  age  age  age  age  age  age  39c  age »?  acs  sje  ace 

-  RETURNS:  * 

*  R0:  SUCCESS  CODE  * 

*  Rl  :  HANDLE  POINTER  * 

^^V^W^WV^  WW  WWW  vV  WW  WW  WW  WW  WWW WWW   ! 


0000  93F2 

0002  5F00 
0004  0062' 


0006  0B00 
0008  0002 

000A  5E0E 
000C  005E' 

000E  91F4 

0010  5F00 
0012  0e00* 


0014  95F0 
0016  1414 
0018  97F1 
001A  93F0 


ENTRY 
!  SAVE  REQUESTED  ACCESS  ! 
PUSH   (?R15,  R2 
!  GET  SEGMENT  HANDLE  ! 
CALL   GET_HANDLE  !R1:SEG  # 

RETURNS : 
R0:SUCCESS  CODE 
R4:HANDLE  PTR 
R5:CLASS  PTR! 
CP    R0,  #SUCCEEDED 

IF  EO   !  SEGMENT  IS  KNOWN  ! 
THEN   !  VERIFY  ACCESS  ! 

!  SAVE  HANDLE  &  CLASS  PTR  ! 

PUSH!  (?R15,  RR4 

!  GET  SUBJECT'S  SAC  ! 

CALL  PROCESS _CLASS  ! RETURNS: 

RR2:PR0C  CLASS! 
!  RETRIEVE  SEG  CLASS  POINTER  ! 
POPL   RR0,  0R15 
!  GET  SEGMENT'S  CLASS  ! 
LDL        RR4,  L*R1 

!  RETRIEVE  REQUESTED  ACCESS  ! 
POP    PI,  0R15 
!  SAVE  HANDLE  POINTER  ! 
PUSH   GR15,  R0 
!  CHECK  ACCESS  CLEARANCE  ! 


Ill 


001C 

0B01 

eeiE 

0000 

0020 

5E0E 

0022 

0040' 

0024 

5F00 

002b 

0000* 

0028 

0B01 

002A 

0000 

002C 

5E0E 

0e2E 

0038' 

0030 

2100 

0032 

0021 

0034 

5E08 

0036 

003C' 

0038 

2100 

003A 

0002 

003C 

5E08 

003E 

0058' 

0040 

5F00 

0042 

0000* 

0044  0E01 
0046  0000 

0048  5E0E 
004A  0054' 
004C  2100 
004E  0029 
0050  5E08 
0052  0058' 
0054  2100 
0056  0002 


005e  97F1 
005A  5E08 
005C  0060' 

005E  97F2 

0060  9E08 
0062 


CP     HI,  #WRITE_ACCESS 

IF  EQ  !  WRITE  ACCESS  REQUESTED  ! 
THEN 

CALL   CLASS_EO  !RR2:PR0CESS  CLASS 

RR4:SEGMENT  CLASS 
RETURNS : 

Rl:  CONDITION  CODE! 
CP     Rl,  #FALSE 

IF  EO  JACCESS  NOT  PERMITTED! 
THEN 

LD   R0,  #ACCESS_CLASS_NOT_EO 

ELSE  JACCESS  PERMITTED! 

LD   R0,  ^SUCCEEDED 

FI 

ELSE  !  READ  ACCESS  REQUESTED  ! 

CALL   CLASS_GE  !RR2:PR0CESS  CLASS 

RR4:SEGMENT  CLASS 
RETURNS: 

Rl:CONDITION  CODE! 
CP    Rl,  #i'ALSE 

IF  EC  IACCESS  NOT  PERMITTED! 
THEN 

LD      R0,  #ACCESS_CLASS_NOT_GE 

ELSE  '.ACCESS  PERMITTED! 

LD   R0,  #SUCCEEDED 

FI 
FI 

!    RETRIEVE   HANDLE    POINTER    ! 
POP         Rl ,    PR15 
ELSE 

!    RESTORE    STACK    ! 
POP        R2,    G>R15 
FI 
RET 
END   CONVERT   AND   VERIFY 
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0062 


3* 


GET  HANDLE  PROCEDURE 

*  CONVERTS  SEGMENT  NUMBER  TO  * 
KST  INDEX  AND  DETERMINES  IF  * 
SEGMENT  IS  KNOWN.  IE  KNOWN  * 
POINTER  TO  SEGMENT  HANDLE  * 
AND  POINTER  TO  SEGMENT  CLASS* 
ARE  RETURNED.  * 

*  PARAMETERS:  * 

*  Rl:  SEGMENT  NUMBER  * 


RETURNS: 

*  R0:  SUCCESS  CODE 

*  R4:  HANDLE  POINTER 

*  R5:  CLASS  POINTER 


0062 

0301 

0064 

000A 

0066 

2100 

0068 

0002 

006A 

0E01 

006C 

0000 

006E 

5E0A 

0070 

007A' 

0072 

2100 

0074 

001C 

0076 

5E08 

0078 

0086' 

007A 

0B01 

007C 

0036 

007E 

5E02 

0080 

0086' 

0082 

2100 

0064 

001C 

0086 

0B00 

0088 

0002 

008A 

5E0E 

008  C 

00BE' 

e08E 

93F1 

ENTRY 
!    CONVERT    SEGMENT   #   TO    KST    INDEX    #    ! 
SUB         Rl,    #NR_OF_KSEGS 

!  VERIFY  KST  INDEX  ! 
LD     R0,  #SUCCEED£D 


CP 


Rl,  #0 


IF    LE    '.INDEX    NEGATIVE! 
THEN 

LD  R0,    #SEGMENT_NOT_KNOWN 

ELSE    ! INDEX    POSITIVE! 

CP  Rl,    #MAX_NO_KST_ENTRIES 

IF      GT    ! EXCEEDS    MAXIMUM    INDEX! 
THEN       ! INVALID    INDEX! 

LD  R0,    #S£GMENT    NOT    KNOWN 


FI 
FI 
CP  R0,    #SUCCEEDED 

IF   EO       ! INDEX    VALID! 
THEN 

!    SAVE   KST    INDEX    ! 

PUSH      @R15,    Rl 

!    GET   KST   ADDRESS     ! 
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0090  2101 
0092  0002 
0094  5F00 
0096  0000* 


0098  97F3 


009A  1902 
009C  0010 

009E  8103 

00A0  41)31 
00A2  000E 
00A4  00FF 


00A6 
00A8 
00AA 
00AC 
00AE 

mm 

00B2 
00  B4 


5E0E 

00B2' 

2100 

001C 

5E08 

00BE' 

2100 

0002 


00B6  7634 

00B8  0000 

00BA  7635 

00BC  000A 


00BE  9E08 
00C0 


LD  Rl,    #KST_SEG_NO 

CALL      ITC_GET_SEG_PTR    ! Rl :KST_SEG_NO 

RETURNS: 
R0:KST   ADER! 

!    P.ETPIEVE   KST    INDEX    #    ! 

POP        R3,    G»R15 

!    CONVERT   KST    INDEX    #    TO    KST    OIFSET    ! 
MULT      RR2,    #SIZEOF   KST_REC 

!  COMPUTE  KST  ENTRY  ADDRESS  ! 

ADD    R3,  R0 

!    SEE    IF    SEGMENT    IS    KNOWN    ! 

CP  KST.M_SEG_N0(R3),    #NOT_KNOWN 

IE    EO    JSEGMENT    NOT    KNOWN! 
THEN 

LD   R0,  #SEGMENT_NOT_KNOWN 

ELSE  ISEGMENT  KNOWN! 

LD   R0,  #SUCCEEDED 

!  GET  HANDLE  POINTER  ! 

LDA    R4f  KST.MM_HANDLE(R3) 

!  GET  CLASS  POINTER  ! 
LDA   R5,  KST.CLASS(R3) 

EI 
FI 
RET 
END   GET_HANDLE 
END    EVENT   MGR 
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APPENDIX  B  -    TRAFFIC  CONTROLLER  LISTINGS 


Z8000ASM      2.02 

LOC           OBJ    CODE           STMT    SOURCE 

STATEMENT 

SLISTON    $TTY 

TC    MODULE 

CONSTANT 

I      jps^siejtejjcjjcjje     SYSTEM     PARAMETERS      ^W*'!''?'!' 

NR    PROC 

!  -    4- 

VP~NR 

=    2 

NR    CPU 

=    2 

NR_KST 

:-    b4 

i    3fimfi3fw>t))i    SYSTEM    CONSTANTS    *?w*wp* 

RUNNING                : 

= 

0 

READY                     : 

:  = 

1 

BLOCKED                : 

;  = 

2 

IDLE   PROC           : 

= 

SDDDD 

NIL 

:  = 

tFFFF 

INVALID               : 

= 

%EEEE 

KERNEL    STACK    : 

!  = 

1 

USER   STACK 

:  = 

KST    SEG                : 

:  = 

2 

KST   LIMIT           : 

= 

1 

USER    FCW 

;  - 

sieee 

WRITE                   : 

:  = 

0 

!  INDICATES    LO'i 

(EST    SYSTEM 

SECURITY    CIAS 

;s 

» 

SYSTEM   LOW         : 

:  = 

0 

STK_OFFSET        : 

= 

SFF 

REMOVED                : 

;  = 

%AjBCD 

TRUE                       : 

= 

1 

FALSE                    : 

= 

0 

SUCCEEDED 

;  = 

2 

TYps 

AP    PTR                WORD 

VP~PTR                WORD 

ADDRESS              WORD 

H    ARRAY             ARRAY  [C 

5 

VORDJ 
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AP  TABLE  RECORD 
[NEXT  AP 
DBR 
SAC 
PRI 
STATS 
AFFINITY 
VP_ID 
HANDLE 
INSTANCE 
VALUE 
FILL  2 


AP  PTR 

WORD 

LONG 

INTEGER 

INTEGER 

WORD 

VP  PTR 

H  ARRA? 

WORD 

LONG 

ARRAY  [2 


WORDJ 


J 

RUN_ARRAY 
RDY_ARRAY 
AP_DATA 
TrP_DATA 
INR  VP 
FIRST 

J 

KST_REC 
[MM_HANDLE 
SIZE 
ACCESS 
IN_CORE 
CLASS 
M_SEG    NO 
ENTRY^NUM 
J 


ARRAY [VP   NH      AP_PTRJ 

ARRAr[NR_CPU    AP_PTRJ 

ARRAY [NR_PROC    AP_TABLIJ 

RECORD 

ARRAI LNR_CPU  rfORDj 

ARRAY [NR~CPU    VP_PTRJ 


RECORD 

H_ARRAY 

WOPD 

BYTE 

BYTE 

LONG 

SHORT  INTEGER 

SHORT  INTEGER 


EXTERNAL 
K_LOCK 
KJJNLOCK 
SET_PREEMPT 
SWAP_VDBR 
IDLE 

RUNNING  VP 
CREATE_lNT_VEC 
LIST_INSERT 
ALLOCATE_MMU 
MM_ALLOCATE 
UPDATE_KMU_IMAGE 
CREATE_STACK 
MM_ADVANCE 
MM_READ_EVENTCOUNT 
G  AST  LOCK 
PREEMPT  RET 


PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

WORD 

LABEL 


lib 


e00e 


00A0 
00A2 


$SECTION 

INTERNAL 

APT 


TC  DATA 


[ 


RECOPD 
LOCK 

RUNNING_LIST 
READY_LIST 
BLOCKED  LIST 
FILL_3 
VP 

FILL 
AP 


J 


WOPD 

RUN_ARRAY 
RDY~ARRA¥ 
AP_PTR 
LONG 
VP_DATA 
ARRAY [4  WORD 
AP  DATA 


! THESE   VARIABLES    ARE   USED    DURING    TC 
INITIALIZATION    TO    SPECIFY    AVAILABLE 
ENTRIES    IN    THE   APT,    AND    ARE    INITIAL- 
IZED   Bv    TC_INIT    IN    THIS    IMPLEMENTATION! 

NEXT_VP  WORD 

APT  ENTRY   WORD 


0000 


0000 


0000 


SSECTION   TC_LCCAL 
$ABS  0 

!NOTE:  USED  AS 
ARG_LIST 
[REG 
IC 

CPU_ID 
SAC1 
PR  II 
tJSR  STK 
KER_STK 
KST1 
J 


OVERLAY  ONLY! 
RECORD 

ARRAY [13  WORD J 

WORD 

WOPD 

LONG 

WORD 

WORD 

WORD 

LONG 


SABS  0 

!NOTE:  USED  AS  STACK  FRAME  FOR 
STORAGE  OF  TEMPORARY  VARIABLES 
FOR  CREATE  PROCESS.  ! 
CREATE      RECORD 
[A?G_PTR    WORD 
DBR  NUM    WORD 
LIMITS     WORD 
SEG_ADDR   ADDRESS 
N  S_P      WORD 

J 


SABS    0 
HANDLE_VAL 
[HIGH 
LOW 

] 


RECORD 
LONG 
WOPD 
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!THE  FOLLOWING  DECLARATION  IS  UTILIZE! 
AS  A  STACK  FRAME  FOR  STORAGE  OF 
TEMPORARY  VARIABLES  UTILIZED  27 
TC_ADVANCE  AND  TC_AWAIT.! 
SABS  0 
0000      TEMP      RECORD 

IHANDLE_PTR  WORD 
EVENT_NR  WORD 
E?ENT_VAL  LONG 
ID_VP  WORD 

CPU  NUM        WORD 
HANDLE_HIGH    LONG 
HANDLE  LOW     WORD 
J 

SSECTION  TC_KST_DCL 
!NOTE:  KST  DECLARATION  IS  USED  HERE 
TO  SUPPORT  KST  INITIALIZATION  FOR 
THIS  DEMONSTRATION  ONLT.   THIS 
DECLARATION  AND  INITIALIZATION 
SHOULD  EXIST  AT  THE  SEGMENT  MANAGER 
LEVEL  AND  THUS  SHOULD  BE  REMOVED 
UPON  IMPLEMENTATION  OF  SYSTEM 
INITIALIZATION.  ! 
$ABS  0 
0000  KST   ARRAI[NR  KST  KST  RSCJ 
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0000 


$SBCTION    TC    INT    PROC 
TC    GETWORK 


PR 


*  PROVIDES    GENERAL    MAN 

*  MENT    OF   USER    PROCESS 

*  EFFECTING    PROCESS    SC 

*  LING    ON    VIRTUAL    PROC 

-  PARAMETERS: 

*  Rl:    CURRENT   VP    ID 

*  R3:    LOGICAL    CPU   # 

r,t  #|*  »,»  SJSSgC  9JC  *,£  *i*  *?•  2jt  3JS  *^%  5J»  JJ*  J»?  S^  i|*  it»  *,»  3JC  Sjj»  *«■ 

*  LOCAL   VARIABLES: 

*  R2:    NEXT   READY    PROC 

*  R4:    AP   FTR 


OCEDURE 

AGE-  * 
ES  BY  - 
REDU-  * 
ESSORS* 

JQB  3?  3QG  3}C  3£  3JC  3QC 

J?  9QB  3QB  3JS  J|»  »,*  2? 

ESS         * 


0000   6132 
0002    0006' 


0004  0E02 
0006  FFFF 
0008  5E0E 
000A  0010' 
000C  5E08 
000E    0026' 

0010  4D21 
0012  002A' 
0014  0001 
0016  5E0E 
0018  001E' 
001A  5E08 
001C    0026' 


001E 
0020 
0022 
0024 
0026 
0028 
002A 
002C 


6124 

0020' 

A142 

E8EF 

0B02 

FFFF 

5E0E 

003C' 


002E    4D15 
0030    0002' 
0032    DDDD 


ENTRV 
!    FIND   FIRST    READY    PROCESS     ! 
ID  R2,    APT.READY_LIST(R3) 

GET_READT_AP: 

DO       '.WHILE   NOT    (END    OF    LIST    OR    READY)! 
CP        R2,    #NIL 

IF    EO    !NO    READY    PROCESS!    THEN 

EXIT    FROM   GET_READY_AP 

FI 

CP        APT.AP.STATE(R2) ,    #READY 

IF   EO    ! PROCESS    READY!    THEN 

EXIT    FROM    GET_READY_AP 

FI 

!    GET    NEXT   AP    FROM    LIST    ! 

LD        R4,    APT.AP.NEXT_AP(R2) 

LD         R2,    R4 
OD 
CP        R2f*NIL 

IF   SO    !    IF    NO    PROCESSES    READY    !    TEEN 

!    LOAD    IDLE    PROCESS     ! 

LD        APT.RUNNING_LIST(R1 ) ,    #IELE_PROC 
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£034  5F00 
0036  0000* 
0036  5E08 
003A  0052' 

003C  6F12 
003E  0002' 
0040  4D25 
0042  002A' 
0044  0000 
0046  6F21 
0048  002S' 
004A  6121 
004C  0022' 
004E  5F00 
0050  0000* 

0052  9E08 
0054 


CALL  IDLE 
ELSE 

!  LOAD  FIRST  READY  AP  ! 

LD    APT.RUNNING_LIST(R1) ,  R2 

LD    APT.AP.STATE(R2)  ,  #RUNNING 

LD    APT.AP.VP_ID(R2)  ,  Rl 

LD    Rl,  APT.AP.DBR(R2) 

CALL  SWAP_VDBR   !(R1:DBR)! 

FI 
RET 
END  TC  GETWORK 
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0054  VIRTUAL_PREEMPT_HANDLER  PROCEDURE 

*  LOADS    FIRST    READY   AP  * 

*  IN   RESPONSE    TO   PREEMPT      * 

*  INTERRUPT  * 

*»*  *i*  "l*  3f* *?  *P  5JS  5J5  S|C  JJS  SQB  3|£  SJ*  !J*  *i!  SJS  ?|*  3JC  7\*  3J»  J",t  2,X  J, J  Jy£  i, %  5,2  3,t    I 


0054    7624 
0056    0000' 
0058    5F00 
005A    0000* 

005C    5F00 
005E    0000* 


0060   6112 
0062    0002' 


ENTRY 
!**  CALL   WAIT   LOCK    (APT". LOCK)    ** ! 
!**   RETURNS    WEEN    PROCESS    HAS    LOCKED    APT    **! 
LDA        R4,    APT. LOCK 

CALL      K_LOCK 

!    GET   RUNNING_VP    ID    ! 

CALL      RUNNlNG_VP       ! RETURNS: 

Rl  :VF_ID 
R3:CPU    #! 

!    GET    AP    ! 

LD  R2,    APT.RUNNING_LIST(R1) 


0064  0E02 
0066  DDDD 
0068  5E06 
006A  0072' 
006C  4D25 
006E  002A' 
0070    0001 


0072    5F00 
0074    0000' 


0076    7604 
0078    0000' 
007A    5F00 
007C    0000* 


!    IF    NOT    AN    IDLE    PROCESS,    SET    IT    TO    READY     I 
CP  R2t    #IDLE_PROC 

IF    NE    !    NOT    IDLE    !      THEN 

LD  APT. AP. STATE (R2)  ,    *READT 


FI 

!    LOAD    FIRST    READY    PROCESS    ! 
CALL    TC_GETWORK       !R1:VP_IE 

R3:CPU   #! 

!NOTE:    THIS    IS    THE    INITIAL    POINT    OF 

EXECUTION    FOP    USER   PROCESSES.! 
7IRT  PREEMPT  RETURN: 

!**   CALL   UNLOCK    (APT". LOCK)    ** ! 

!**  RETURNS    WHEN    PROCESS    HAS    UNLOCKEE    AP^    ** ! 

!**   AND    ADVANCED    ON    THIS    EVENT    **! 

LDA        R4,    APT. LOCK 

CALL      K    UNLOCK 
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!  PERFORM  A  VIRTUAL  INTERRUPT  RETURN  ! 

!NOTE:  THIS  JUMP  EFFECTS  A  VIRTUAL 
I3ET  INSTRUCTION.! 
007E  5E08     JP    PREEMPT_RET 
0080  0000* 
0082       END  VIRTUAL  PREEMPT  HANDLER 
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GLOBAL 

$SECTION  TC_G-LB_PROC 

0000        TC_INIT  PROCEDURE 

'*  INITIALIZES  APT  HEADER     * 

*  AND  VIRTUAL  INT  VECTOR     * 

*  PARAMETERS:  * 

*  Rl :  CPU_ID  * 

*  R2:  NR_VP  - 

ENTRT 

!  NOTE:  THE  NEXT  FOUR  VALUES  ARE 
ONLY  TO  BE  INITIALIZED  ONCE.  ! 
LD    NEXT  VP,  #0 


0000 

4D05 

0002 

00A0' 

0004 

0000 

0006 

4D05 

0008 

00A2' 

000A 

0000 

000C 

4D05 

000E 

000A' 

0010 

FFFF 

0012 

4D08 

0014 

0000' 

0016  2104 
0018  0000 

001A  0E04 
001C  0004 

001E  5E0E 
0020  0026' 
e022  5E08 
0024  0036' 


LD    APT_ENTRY,  *0 


LD 


APT.BLOCKED_LIST,  #NIL 


CLR   APT. LOCK 

NOTE:  THE  FOLLOWING  CODE  IS  INCLUDED 
ONLY  FOP.  SIMULATION  OF  A  MULTIPROCESSOR 
ENVIRONMENT.   THIS  IS  TO  INSURE  THAT  THE 
READY  LIST(S)  AND  VP  DATA  OF  THE  SIMULATED 
C?U(S)  APE  PROPERLY  INITIALIZED.   IN  AN 
ACTUAL  MULTIPROCESSOR  ENVIRONMENT,  THIS 
BLOCK  OF  CODE  SHOULD  BE  REMOVED. 

LD     R4t  #0 


DO 


CP     R4,  #NR_CPU*2 

IF  EO  !ALL  LISTS  INITIALIZED? 
THEN  EXIT 


FI 
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0026  4D45 
0028  0006' 
002A  FFFF 


002C  4D45 
002E  0010' 

0030  0001 
0032  A941 
0034  E8F2 


0036  6F12 
0038  0010' 

003A  6103 

003C  00A0' 

003E  6F13 

0040  0014' 


0042 
0044 
0046 
0048 
004A 
004C 

004E 
0050 

0052 
0054 
0056 
0058 
005A 
005C 
005E 
0060 
0062 
0064 
0066 
006e 
006  A 
006C 
006E 


A125 
1904 
0002 
8153 
6F03 
00A0' 

6113 
0014' 

0E02 

0000 

5E0E 

005E' 

5E08 

006A' 

4D35 

0002' 

DDDD 

A931 

AB20 

E8F4 

4D15 

0006' 

FFFF 


!  INITIALIZE  READY  LISTS  AS  EMPTY  ! 
LD     APT.READY_LIST(R4) ,  #NIL 


!  INITIALLY  MARK  ALL  LOGICAL  CPU'S 
AS  HAVING  1  VP.   THIS  IS  NECESSARY 
TO  INSURE  TC  ADVANCE  WILL  FUNCTION 
PROPERLY,  AS "IT  EXPECTS  EVERY  CPU 
TO  HAVE  AT  LEAST  1  VP .  ! 

LD     APT.VP.NR  VP(R4),  #1 


INC    R4,  #2 
OD 
!  END  MULTIPROCESSOR  SIMULATION  CODE. 

LD        APT.VP.NR_VP(R1) ,  R2 

LD    R3,  NEXT_VP 

LD    APT.VP.FIRST(Rl),  R3 

!  RECOMPUTE  NSXT_VP  VALUE  FOR  TC 
INITIALIZATION  OF  NEXT  LOGICAL 
CPU.  ! 

LD    R5,  R2 

WULT  RR4t  #2 

ADD   R3,  R5 

LD    NEXT_VP,  R3 

!  INITIALIZE  RUNNING  LIST  ! 
LD    R3,  APT.VP.FIRST(Rl) 

DO 

CP   R2,  *0 

IF  EO  TEEN  EXIT  FI 


LD    APT. RUNNING  LIST(R3>,  #IDLE  PRCC 


INC   R3,  #2 

DEC   R2t  #1 
OD 

LD  APT. READY  LIST(Bl),  #NIL 
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0070  2101 
0072  0000 

0074  7602 
0076  00t>4' 
0078  5F00 
007A  0000* 


007C  9E08 
007E 


LD 


Rl,  #0 


!  ENTRY  ADDRESS  ! 

LDA   R2,  VIRTUAL_PREEr*PT_HANDLER 

CALL    CREATE_INT_JSC 

!R1:VIRTUAL  INTERRUPT  * 
R2: INTERRUPT  HANDLER  ADDRESS! 
?ET 
END  TC  INIT 
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CREATE    PROCESS      PROCEDURE 

*  CREATES    USER    PROCESS      ;s 

*  DATABASES    AND    APT  * 

*  ENTRIES  * 

i,C  3|5  J,  J  *J»  2^C  3gC  3|S  5JC  2jS  2,i  *»»  J,£  5,i  J,i  *^  JJI  3jC  i,«  J, I  5j?  5»C  *,*  ;,  i  3^£  »»* 

*  PARAMETERS:  * 

*  R14:    ARGUMENT    PTR  * 


007E   030F 
0080    000A 

0082  6FFE 
0084    0000 

0086  7604 

0088  0000' 

008A  5E00 

008C  0000* 


008E    5F00 
0090    0000* 


0092  6101 
0094    00A2' 

0096  2102 
0098  0020 
009A   8112 

009C  6F02 
009E    00A2' 

00A0   4D15 
0eA2    0020' 
00A4   FFFF 
00A6   6F10 
00A8    0022' 

00AA  54E2 
00AC    001E 

00AE    5D12 


ENTRY 
!N0TE:    THIS    PROCEDURE    IS    A    STUB    TO    ALLOW 
PROCESS    INITIALIZATION    FOR    THIS 
DEMONSTRATION. ! 
!    ESTABLISH    STACK   FRAME    FOR    L0C/\L 

VARIABLES.     ! 
SUB        R15,    #SIZEOF    CREATE 

!    STORE    INPUT    ARGUMENT    POINTER    ! 
ID  CREATE. ARG_PTR(R15) ,    R14 

!    LOCK   APT    ! 

LDA        R4,    APT. LOCK 

CALL      K_LOCK 

!    RETURNS    WHEN    APT    IS    LOCKED    ! 
!    CREATE    MMU   ENTRT    FOR    PROCESS    ! 
CALL      ALLOCATE_MMU    {RETURNS: 

R0:    DBR    #! 
!    GET    NEXT    AVAILABLE    ENTRI    IN    APT    I 
LD  Rl,    APT_ENTRY 

!    COMPUTE    APT    OFFSET    ! 

LD  R2,    #SIZEOF    AP_TABLE 

ADD        R2,    Rl 

!    SAVE    NEXT   AVAILABLE    APT    ENTRY    ! 

LD  APT_ENTRY,    R2 

!    CREATE   APT    ENTRY    FOR    PROCESS    ! 
LD  APT. AP. NEXT    AP(Rl),    #NIL 


LD 


APT.AP.DBR(Rl),    R0 


!    GET    PROCESS    CLASS     ! 

LDL        RR2,    ARG_LIST.SAC1(R14) 

LDL        APT.AP.SAC(Rl) ,    RR2 
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00B0  0024' 

00B2  61E2 
00B4  0022 
00B6  6F12 
00B8  0028' 

00BA  61E2 

00BC  001C 

00BE  6F12 

00C0  002C' 


00C2 
00C4 
00C6 
00C8 
00  C  A 
00CC 
00CE 
00D0 
00D2 
00D4 
00D6 


7623 

0006' 

7604 

0020' 

7605 

0028' 

7606 

002A' 

2107 

0001 

AD21 


00D8  6FF0 
00DA  0002 
00DC  5F00 
00DE  0000* 


00E0  7604 
00E2  0000' 
00E4  5F00 
00E6  0000* 


00E8  61FE 
00EA  0000 
00EC  61E3 
00EE  0024 

00F0  6FF3 
00F2  0004 


!  GET  PROCESS  PRIORITY  ! 

ID    R2,  ARG_LIST.PRI1(R14) 


ID 


APT.AP.PRI(Rl),  R2 


!  GET  LOGICAL  CPU  #  ! 

LD     R2,  APG  LIST. CPU  ID(R14) 


LD 


APT.AP.AFFINITY(RI),  R2 


!THREAD  IN  LIST  AND  MAKE  READY! 
LDA    R3,  APT.READY_LIST(R2) 


R4,  APT.AP.NEXT_AP 

R5,  APT. AP. PR  I 

R6,  APT. AP. STATE 

R7,  #READY 


LDA 

LDA 

LDA 

LD 

EI     Rl,  R2 

!  SAVE  DER  #  ! 

LD     CREATE. DBR_NUM(R15)  ,  R0 

CALL   LIST  INSERT 


!R2: 

OBJ  ID 

R3: 

LIST  HEAD  PTR 

R4: 

NEXT  OBJ  PTR 

R5: 

PRIORITY  PTR 

R6: 

STATE  PTR 

R7: 

STATE! 

!  UNLOCK  APT  ! 
LDA    R4,  APT. LOCK 

CALL   KJJNLOCK 

!CREATE  USER  STACK! 

!  RESTORE  ARGUMENT  POINTER  ! 

LD     R14,  CREATE. ARG  PTR(RIS) 


LD 


R3,  ARG  LIST.USR  STK(R14) 


!  SAVE  LIMITS  ! 

LD    CREATE. LIMITS (R15),  R3 
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00F4  5F00 
00F6  0000* 


00F8  A128 


00FA  0108 
00FC  00FF 
00FE  6FF8 
0100  0008 

0102  61F4 
ei04  0e04 
0106  AM0 


0108 
010A 
010C 
010E 
0110 
0112 
0114 
0116 


61F0 
0002 
2101 
0003 
2103 
0000 
5F00 
0000* 


0118  61FE 
011A  0000 
011C  61E3 
011E  0026 
0120  5F00 
0122  0000* 


CALL   MM_ALLOCATE  ! R3 :  #  OF  BLOCKS 

RETURNS : 
R2:  START  ACER! 
!COMPUTE  &  SAVE  NSP! 

LD     R8,  R2 

!  ESTABLISH  INITIAL  SP  VALUE 

FOR  USER  STACK.  ! 
ADD    R8,  #ST5  OFFSET 


LD 


CREATE. N_S_P(R15) ,  R8 


!  RESTORE  LIMITS  ! 

LD     R4,  CREATE. LIMITS(R15) 

DEC    R4   !SEG  LIMITS ! 

!  RESTORE  DBR  ! 

LD     R0,  CREATE.  DBR_\'UM  (R15 ) 

LD     Rl,  #USER_STACK 

LD    R3,  #WRITE   .'ATTRIBUTE! 

CALL   UPDATE_MMU_IMAGE 

!R0:  DBR  tt 

Rl:  SEGMENT  * 

R2:  SEG  ADDRESS 

R3:  SEG  ATTRIBUTES 

R4:  SEG  LIMITS ! 
! CREATE  KERNEL  STACK! 
!  RESTORE  ARGUMENT  POINTER  ! 
LD    Rl*,  CREATE. ARG_PTR (Rib) 

LD     R3,  ARG_LIST.KER_STK(R14) 

CALL      MM_ALLOCATS    !R3:    #    OF   BLOCKS 

RETURNS 

R2:  START  ADER  ! 

!MAKE  MMU  ENTRY! 

!  RESTORE  DBR  n    ! 


0124 

61F0 

LD 

R0, 

CREATE 

0126 

0002 

0128 

2101 

LD 

Rl, 

#KERNE 

012A 

0001 

012C 

A 134 

LD 

R4, 

R3 

012E 

AB40 

DEC 

R4 

0130 

2103 

LD 

R3, 

#WRITE 

0132 

0000 

!  SAVE  START  ADDRESS  ! 
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0134  6FF2 
0136  0006 
0138  5F00 
013A  0000* 


013C  61FE 
013E  0000 

0140  61F1 
0142  0006 
0144  2103 
0146  1800 
0148  61E4 
014A  001A 


014C 
014E 
0150 
0152 
0154 
0156 
0158 
015A 


61F5 
0008 
7606 
0076 
030F 
0008 
1CF9 
0303 


015C  A1F0 
015E  93F1 
0160  A1E1 


0162  5C11 
0164  020C 
0166  0000 
0168  97F1 
016A  5F00 
016C  0000* 


LD     CREATE. SEG_ADDR(R15)  ,  R2 
CALL   UPDAT£_MMU_IMAGE 

!R0:  DER  # 

fil:  SEGMENT  # 

R2:  SEG  ADDRESS 

R3:  SEG  ATTRIBUTES 

R4:  SEG  LIMITS! 

!ESTAELISH  ARGUMENTS! 
!  RESTORE  ARGUMENT  POINTER  ! 

ID  R14t  CREATE  ,ARG_PTR(Rl 5) 

!  RESTORE  STACK  ADDRESS  ! 

LD     Rl,  CREATE. SEG_ADDR (R15 ) 

LD     R3,  #USER_FCW 

LD     R4,  ARG_LIST.IC(R14) 

!  RESTORE  INITIAL  NSP  ! 

LD     R5,  CHEATS. N_S_P(R15) 

LDA    R6,  VIRT_PREEMPT_RETURN 

SUB    R15,  #8 

LDM        G>R15,    R3t    #4 

!  LOAD  ARGUMENT  POINTER  FOR 

CREATE  STACK  CALL  ! 
LD     R0,  R15 
PUSH   PR15,  Rl 
LD     Rl,  R14 
!  LOAD  INITIAL  REGISTER  VALUES  TO 

BE  PASSED  TO  USER  PROCESS  AS 

INITIAL  PARAMETERS.  ! 
LDM   R2,  ARG  LIST. REG (Rl ) ,  #13 


POP    Rl,  G»R15 
CALL   CREATE_STACK 

!R0:  ARGUMENT  PTR 
PI:  TOP  OF  STACK 
R2-R14:  INITIAL 
REG  STATES! 
!NOTE:  THE  ABOVE  INITIAL  REG  STATES 
REPRESENT  THE  INITIAL  PARAMETERS 
(VIZ.,  REGISTER  CONTENTS )    THAT  A 
USER  PROCESS  WILL  RECEIVE  UPON 
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INITIAL  EXECUTION.  ! 
ei6E  010F    ADD   R15,  #8   IOVERLAY  PARAMETERS! 
0170  0008 

!  ALLOCATE  KST  ! 
0172  2103     LD     R3,  #KST_LIMIT 
0174  0001 

017b  5F00     CALL   MM_ALLOCATE  !P.3:#  OF  BLOCKS 
0178  0000* 

RETURNS 
R2:START  AEDR! 

!  RESTORE  DBR  ! 
017A  61F0     LD     R0,  CREATE  .DBR_NUM(R15  ) 
017C  0002 

!  SAVE  KST  ADERESS  ! 
017E  6FF2     LD     CREATE. SEG_ADDR( R15 ),  R2 
0180  0006 

!MAKE  MMU  ENTRY  FOR  KST  SEG! 
0182  2101     LD     Rl,  #KST_SSG 
0184  0002 

0186  2103     LD     R3,  #WRITE  IATTRIBUTE! 
0188  0000 

018A  2104     LD     R4,  #KST_LIMIT-1 
018C  0000 

018E  5F00     CALL   UPDATE_MMU_IMAGE 
0190  0000* 


DBR  # 
SEGMENT  # 
SEG  ADDRESS 
SEG  ATTRIBUTES 
SEG  LIMITS ! 


!R0 
Rl 
R2 
R3 
R4 

!  RESTORE  KST  ADDRESS  ! 
0192  61F2     LD     R2,  CREATE. SEG_ADDR (Rl 5 ) 
0194  0006 

0196  5F00 
0198  01A0' 


!  CREATE  INITIAL  KST  STUB  ! 
0196  5F00     CALL   CREATE  KST  !R2:KST  ADDR ! 


!  REMOVE  TEMPORARY  VARIABLE 
STACK  FRAME.  ! 
ei9A  010F     ADD    R15,  #SIZEOF  CREATE 
019C  000A 
019E  9E08     RET 
01A0         END  CREATE  PROCESS 
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01A0 


CREATE   KST 


PROCEDURE 


f    ;,-  »r*  *|5  *|S »jS  3J%  ^*  *|t  *|*  J,C  3y»  J,  J  2,i  J,i  #,C  Xfi  *«*  J,S  J^C  i,C  i,i  5p  *i*  J,i 

*  CREATES    KST    STUB   FOR    * 

*  PROCESS    MANAGEMENT         * 

*  DEMO.       INSERTS    ROOT      * 

*  ENTRY    IN    KST.      NOT         * 

*  INTENDED    TO    BE   FINAL    * 

*  PRODUCT.  * 

*  PARAMETERS:  * 

*  R2:    KST   ADDRESS  - 

ENTRY 
!NOTE:    THIS    PROCEDURE    IS    A    STUB   USED 
FOR    INITIALIZATION    IN    THIS    IMPLEMENTATION 
ONLT.      THE    ACTUAL    INITIALIZATION    COD* 
FOR    THE   KST   WILL   RESIDE    i>T    THE    SEGMENT 
MANAGER    LEVEL    ONCE    IMPLEMENTATION    OF 
SYSTEM    INITIALIZATION    IS    EFFECTED.     ! 


01A0  1406 
01A2  FFFF 
01A4  FFFF 
01A6  5D26 
01A8    0000 

01AA  4D25 
01AC  0004 
01AE    0£00 

01B0  1406 
01B2  0000 
01B4  0000 
01B6  5D26 
01B8    000A 

01BA  4C25 
01BC  000E 
013E    0000 


01C0    2101 
01C2    000A 

01C4    0E01 
01C6    0000 

eice  5E0E 

01CA   01D0' 
01CC    5E08 


!    CREATE   ROOT    ENTRY    IN    KST    ! 
LDL        RR6,    #-1       !ROOT    HANDLE! 


LDL         KST.MM_EANDLE(R2) t    RR6 

!SET    ROOT    ENTRY    ft    IN    G    AST    ! 
LD  KST.MM_HANDLE[2J7R2) ,    *0 


!    SET    ROOT    CLASSIFICATION    ! 
LDL        P.R6,    ^SYSTEM    LOW 


LDL        KST. CLASS (R2) ,    RR6 

!SET    MENTOR    SEG   #! 

LDB        KST.M    SEC-    N0(R2)  ,    #0 


UNITIALIZE   FREE    KST    ENTRIES 

FOR    DEMO.    NOT    FULL    KST! 
LD  Rl,    #10 

DO 
CP        Rl,    #0 

IF   EC    THEN    EXIT   FI 
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01CE  01DE' 

eiD0  0102     AM   R2,  #SIZEOF  KST_R£C 

01D2  0010 

01D4  4C25      IDE   KST.  M_SEG_N0(R2  )  ,  #%T$ 

01D6  000E 

01D8  FFFF 

01DA  AB10      DEC   Rl 

01DC  E8F3     OE 

01DE  9E08     RET 

01E0         END  CREATE  5ST 
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01E0 


TC_ADVANCE  PROCEDURE 

*  EVENTCOUNT  IS  ADVANCED  BY     * 

*  INVOCATION  OF  MM  ADVANCE. 

*  PROCESSES  THAT  AHE  AWAITING   * 

*  THIS  EVENT  OCCURRENCE  ARE     * 

*  REMOVED  FROM  THE  BLOCKED  LIST* 

*  AND  MADE  READY.   THE  READY    * 

*  LISTS  ARE  THEN  CHECKED  TO     * 

*  INSURE  PROPER  SHEDULING  IS    * 

*  EFFECTED.   IF  NECESSARY  VIR-  * 

*  TUAL  PREEMPTS  ARE  SENT  TO  ALL* 

*  THOSE  VP'S  BOUND  TO  LOWER     * 

*  PRIORITY  PROCESSES.  * 

-  PARAMETERS:  * 

*  Rl:  HANDLE  POINTER  * 

*  R2:  INSTANCE  (EVENT  #)       * 

*  RETURNS :  * 

*  R0:  SUCCESS  CODE  * 


01E0  030F 
01E2  0012 

01E4  6FF1 
01E6  0000 
01E8  6FF2 
01EA  0002 

01EC  7604 
01EE  0000' 
01F0  5F00 
01F2  0000* 


01F4  5F00 
01F6  0000* 


01FB  0B00 

01FA  0002 

01FC  5E0E 

01FE  0372' 


ENTRY 
!  ESTABLISH  TEMPORARY  VARIABLE 

STACK  FRAME.  ! 
SUB    R15,  #SIZE0F  TEMP 

!  SAVE  INPUT  ARGUMENTS  ! 

LD     TEMP. HANDLE  PTR(R15)f  Rl 


LD 


TEMP. EVENT  NR(R15),  R2 


!  LOCK  APT  ! 

LDA    R4,  APT. LOCK 

CALL   K_L0CK 

!  RETURNS  WHEN  APT  IS  LOCKED  ! 
!  ANNOUNCE  EVENT  OCCURRENCE  BY 

INCREMENTING  EVENTCOUNT  IN  G  AST! 
CALL   MM_ADVANCE  !R1:HANDLE  PTR 

R2: INSTANCE 
RETURNS : 
R0:SUCCESS  CODE 
RR2:EVENTC0UNT! 
CP    R0,  #SUCCEEDED 

IF  EO  THEN 
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0200 

5DF2 

0202 

0004 

0204 

61F0 

0206 

0002 

0208 

61  Fl 

020A 

0000 

020C 

5414 

020E 

0000 

0210 

5DF4 

0212 

000C 

0214 

6114 

e216 

0004 

0218 

6FF4 

021A 

0010 

021C 

6101 

021E 

000A' 

0220 

7606 

e222 

000A' 

0224  0B01 
0226  FFFF 

0228  5E0E 
022A  0230' 
022C  5E08 
022E  02B4' 


0230  6117 
0232  0020' 


0234  54F4 
0236  000C 
0238  5014 
023A  0030' 

023C  5E0E 
023E  02A2' 
0240  61F4 
0242  0010 
0244  4B14 


!  SAVE  EVFNTCOUNT  ! 

LDL    TEMP.EVENT_VAL(R15)  ,  RR2 

!  RESTORE  INSTANCE  ! 

LD     R0t  TEMP.EVENT_NR(Rlb) 

!  RESTORE  HANDLE  POINTER  ! 

ID     Hi,  TEMP.HANDLE_PTR(R15) 

!    SAVE   HANDLE    ! 

LDL        RR4,    HANDLE_VAL.HIGH(Rl ) 

LDL        TEMP.HANDLE_HIGH(R15),    RR4 

LD  F.4,    HANDLE_VAL.LOW(Rl) 

LD     TEMP.FANDLE_L0W(R15) ,  R4 

!  AWAKEN  ALL  PROCESSES  AWAITING 

THIS  EVENT  OCCURRENCE  ! 
!  GET  FIRST  BLOCKED  PROCESS  ! 
LD    Rl,  APT.BLOCKED_LIST 

LDA    R6,  APT.BLOCKED_LIST 

WAKE_UP: 
DO 
!  DETERMINE  IF  AT  END  OF  BLOCKED  LIST  ! 
CP     Rl,  #NIL 

IF  EC  !  NO  MORE  BLOCKED  PROCESSES  ! 
THEN  EXIT  FROM  WAKE  UP 


FI 

!  SAVE  NEXT  ITEM  IN  LIST  ! 

LD     R?,  APT.AP.NEXT_AP(R1) 

!    DETERMINE    IF   PROCESS    IS    ASSOCIATED 

WITH    CURRENT    HANDLE    ! 
LDL         RR4,    TEMP.HANDLE_HIGH(R15) 

CPL        RR4,    APT.AP.HANDIE(RI) 

IF   EC    '.HIGH    HANDLE   VALUE    MATCHES! 
THEN 

LD  R4,    TEMP.HANDLE_L0W(R15) 

CP  R4,    APT. AP  .HANDLE [2J  (Rl ) 
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0246 

0034' 

0248 

5E0E 

024A 

029C' 

024C 

61F0 

024E 

0002 

0250 

4E10 

0252 

0036  ' 

0254 

5E0E 

0256 

0296' 

025e 

54F2 

025A 

0004 

025C 

5012 

025E 

0038' 

0260 

5E01 

0262 

0290' 

0264 

2F67 

0266 

91F6 

0268 

6112 

026A 

002C' 

026C 

7623 

026E 

0006' 

0270 

7604 

0272 

0020' 

0274 

7605 

0276 

0028' 

0278 

7606 

027A 

002A' 

027C 

2107 

027E 

0001 

0280 

A112 

0282 

5F00 

0284 

0000* 

0286  95F6 
0288  210B 
028A  ABCD 
028C  5E08 


IF  Eg  !  HANDLE'S  MATCH  ! 
THEN  !  CHECK  FOR  INSTANCE  MATCH  ! 

LD    R0,  TEMP.EVENT_NR(R1S) 

CP     R0,  APT. AP. INSTANCE (Rl) 

IF  EQ  !  INSTANCE  MATCHES  ! 
THEN  !DETERMInE  IF  THIS  IS  THE 

OCCURRENCE  THE  PROCESS 
WAITING  FOR  ! 
LDL        RR2,  TEMP.EVENT_VAL(R15) 

CPL    RR2,  APT. AP. VALUE (Rl) 

IF  GE  ! AWAITED  EVENT  HAS  OCCURRED! 
THEN  !  AWAKEN  PROCESS  ! 

!  REMOVE  FROM  SLOCKED  LIST  ! 

LD     G»R6,  R7 

!  SAVE  LOCAL  VARIABLES  ! 

PUSHL  0R15,  RR6 

!SET  LIST  THREADING  ARGUMENTS! 

LD     R2t  APT.AP.AFFINlTY(Hl) 

LDA  R3,  APT.READY_LIST(R2) 

LDA  R4,  APT.AP.NEXT_AP 

LDA  P5,  APT. AP. PR  I 

LDA  R6,  APT. AP. STATS 

LD  R7,  #READr 

LD     R2t  Rl 
CALL   LIST_INSERT 

!R2:  OEJ  ID 

R3:  LIST  HEAD  PTR 

R4:  NEXT  OBJ  PTR 

R5:  PRIORITY  PTR 

R6:  STATE  PTR 

R7:  STATE  VALUE  ! 
!  RESTORE  LOCAL  VARIABLES  ! 
POPL   RR6.  0R15 
LD     Rllt  #REMOVED 

ELSE  !PROCESS  STILL  BLOCKED! 
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028E  0292' 
0290  8DB8 

0292  5E08 
0294  0298' 
0296  8DB8 

0298  5E08 
029A  029E' 
029C  8DB8 

029E  5E08 
02A0  02A4' 
02A2  8DES 


02A4  0B0B 
02A6  AECD 

02A8  5E06 
02AA  02B0' 
02AC  7616 
02AE  0020' 

02B0  A171 
02B2  E8B8 


02B4  3D28 


02B6  0B02 
02B8  0004 
02BA  5E0E 
02BC  02C2' 
02BE  5E08 
02Ce  0366' 


02C2  8D18 

02C4  A910 
02C6  4B21 
02C8  0010' 

02CA  5E02 
02CC  02D2' 
02CE  5E08 
02D0  02D8' 

02D2  0DF9 


CLR    Rll 
EI  !  END  VALUE  CHECK  ! 
ELSE  JPROCESS  STILL  BL0CKET! 

CLR    Rll 
FI  !  END  INSTANCE  CHECK  ! 
ELSE   !PROCESS  STILL  BLOCKED! 

C  LR   Rll 
FI  !  END  HANDLE  CHECK  ! 
ELSE   IPROCESS  STILL  BLOCKED! 

CLR    Rll 
FI  !  END  HIGH  HANDLE  CHECK  ! 
!  RESET  AP  POINTER  REGISTERS  ! 
CP    Rll,  #REMOVED 

IF  NE  !  PROCESS  IS  STILL  BLOCKED  ! 
THEN 

LDA    R6,  APT. AP. NEXT  AP(R1) 


Rl,  R7 


FI 
LD 
OD 
!  DETERMINE  IF  ANY  VIRTUAL  PREEMPT 

INTERRUPTS  ARE  REQUIRED  ! 
CLR    R2 
PREEMPT  CHECK: 
DO 
CP     R2,  #NR_CPU  *  2 

IF  EC  !ALL  READ*  LISTS  CHECKED!  THEN 

EXIT  FROM  PREEMPT_CHECK 

FI 

!  CREATE  PREEMPT  VECTOR  FOR  VP'S  ! 

CLR    Rl 

DO  IFOR  Rl=l  TO  NR_VP'S! 

INC    Rl 

CP     Rl,  APT.VP.NR_VP(R2) 

IF  GT  !  PREEMPT  VECTOR  COMPLETFD  ! 
THEN  EXIT 


FI 

PUSH      C3R15,    #TRUE 
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02D4  0001 
02D6  E8F6 

02D8  8D38 
e2DA  6124 
02DC  0010' 


02DE  6121 
02E0  0006' 


02E2  0E01 
02E4  FFFF 

02E6  5E0E 
02E8  02EE' 
02EA  5E08 
02EC  0324' 

02EE  4D11 
02F0  002A' 
02F2  0000 

e2F4  5E0E 
02F6  030C' 
02F8  6115 
02FA  002E' 


02FC 
02FE 
0300 
0302 
0304 
0306 
0308 
030A 
030C 


4325 

0014' 

74F6 

0500 

0D65 

0000 

5E08 

030E' 

A930 


030E  A£40 
0310  0B04 
0312  0000 

0314  5E0E 
0316  031C' 
e318  5E08 
031A  0324' 


031C  6110 


OD 

!  #  TO  PREEMPT  ! 

C  LR  R3 

ID"  R4,  APT.VP.NRJTP(R2) 

!  #  OF  VP'S  ! 

!  GET  FIRST  READY  PROCESS  ! 

LD    HI,  APT.READY_LIST(R2) 

CHECK_RDY_LIST: 
DO 
!    SEE    IF   READY    LIST    IS    EMPTY    ! 
CP  Rl,    #ML 

IF    EO    !LIST    IS    EMPTY! 
THEN    EXIT   FROM   CHECK   RDY    LIST 


FI 
CP 


APT.AP.STATE(R1 ),  ^RUNNING 


IF  EO  JPROCESS  IS  RUNNING! 
THEN  !BON'T  PREEMPT  IT! 


LD 


R5t  APT.AP.VP_ID(R1) 


! COMPUTE  LOCATION  IN  PREEMPT  VECTOP! 
SUB   R5,  APT. VP. FIRST (R2) 

LDA    R6,  R15(R5) 

LD    (?R6,  #FALSE 

ELSE  !  PREEMPT  IT  ! 

INC    R3 
FI 

DEC    R4 
CP     R4t  #0 

IF  EO   !ALL  VP'S  VERIFIED! 
THEN 

EXIT  FROM  CHECK_RDY_LIST 

FI 

!  GET  NEXT  AP  IN  READY  LIST  ! 

LD     R£,  APT. AP. NEXT  AP(Rl) 
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031E  0020' 
0320  A101 
0322  E8DF 

0324  6124 
0326  0010' 
0328  6121 
032A  0014' 


032C  97F0 

032a  0P00 
0330  0001 

0332  5E0E 
0334  0350' 
0336  0B03 
0338  0000 

033A  5E02 
033C  0350' 

033E  93F1 
0340  91F2 
0342  93F4 
0344  5F00 
0346  0000* 


0348  97F4 

034A  95F2 

e34C  97F1 

034E  AB30 


0350  A911 
0352  A240 
0354  0B04 
0356  0000 

0358  5E0E 

035A  0360' 

035C  5E08 

035E  0362' 

0360  E8E5 

0362  A921 

0364  E8A8 


ID  Rl,    R0 

OD       !END    CHECK_RDY_LIST! 
!    SET   NECESSARY    PREEMPTS    ! 
ID  R4,    APT.VP.NR_VP(R2) 

LD  Rl,    APT.VP.FIRST(R2) 

SEND_PREEMPT: 
DO 
POP    R0,  5R15 
!  CHECK  TEMPLATE  ! 
CP     ?.0,  #TRUE 

IF  EQ  !CAN  EE  PREEMPTED! 
THEN 


CP 


R3,  #0 


IF  GT  IPREEMPTS  REQUIRED! 
THEN  .'PREEMPT  IT! 

!SAVE  ARGUMENTS! 

PUSH  (?R13.  Rl 

PUSHL  GF.15,  RR2 

PUSH  PR15,  R4 

CALL  SET_PREEMPT 

!Pl:  VP  ID! 
!  RESTORE  ARGUMENTS  ! 
POP    R4,  GRlb 
POPL   RR2,  f3R'l5 
POP    Rl,  (?R15 
DEC    R3 


FI 

FI 

INC 

Rl, 

#2 

DEC 

R4 

CP 

R*. 

*e 

IF    EO 

! STACK 

RE 

ISTORED! 

THEN 

EXIT 

FI 
OD  !END  SEND_PREEMPT! 
!  CHECK  NEXT  READY  LIST  ! 
INC    R2,  #2 
OD  !END  PREEMPT  CHECK! 
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!  UNLOCK  APT  ! 

0366  7604     IDA    R4,  APT. LOCK 

0368  0000' 

036A  SF00     CALL   K_UNLOCK 

036C  0000* 

e36E  2100 

0370  0002 


!  RESTORE  SUCCESS  CODE  ! 
e36E  2100     ID     R0,  #SUCCEEDED 


FI 

!  RESTORE  STACK  ! 
0372  010F     ADD    R15,  #SIZEOF  TEMP 
0374  0012 
0376  9E08     RET 
0378         END  TC  ADVANCE 
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0  378 


0378  030F 
037A    0012 

037C  em 
037E  0000 
0380  6FF2 
0382  0002 
0384  5DF4 
0386    0004 

0388    7604 
038A    0000' 
038C    5F00 
038E    0000* 


0390    5F00 
0392    0000* 


0394  0B00 
0396  0002 
0398  5E0E 
039A   0440' 


TC    AWAIT  PROCEDURE 

*  CHECKS    USER    SPECIFIED    VALUE  * 

*  AGAINST    CURRENT    EVENTCOUNT 

*  VALUE.    IF    USER    VALUE    IS    LESS  * 

*  THAN    OP    EQUAL    EVENTCOUNT    THEN* 

*  CONTROL    IS    RETURNED    TO   USER.  * 

*  ELSE    USER    IS    BLOCKED   UNTIL  * 

*  EVENT   OCCURRENCE.  * 

3,i  ?|i  ifi  *|C  *|»  i,C  #|*  ifi  ifi  *,»  *j£  S|£  J,C  »,*  5,i  ^J  £|£    i,-  -,i  *,*   -j*  ^,i    *,t  5|*  *,»  *gS  »,»  2,i  5,1   *,*  5,i  *,i 

*  PARAMETERS :  * 

*  Rl:    HANDLE    POINTER  * 

*  R2  :    INSTANCE    (EVENT   #)  * 

*  RR4:    SPECIFIED    VALUE  * 

*  RETURNS :  * 

*  R0:    SUCCESS    CODE  * 

ENTRY 
!    ESTABLISH    STACK    FRAME   FOR 

TEMPORARY    VARIABLES.     ! 
SUB         R15,    #SIZEOF    TEMP 

!    SAVE    INPUT    PARAMETERS     ! 

LD  TEMP.HANDLE_PTR(R15) ,    Rl 

LD  TEMP. EVENT_NR( Rib ),    R2 

LDL        TEMP.EVENT_VAI(R15) ,    RR4 

!     LOCK    APT    ! 

LDA        R4,    APT. LOCK 

CALL      K_LOCK 

!    RETURNS    WHEN    APT    IS    LOCKET    ! 
!    GET    CURRENT    EVENTCOUNT    ! 
CALL      MM_READ_EVENTCOUNT 

!Rl: HANDLE    POINTER 

R2:INSTANCE 
RETURNS: 

R0:SUCCESS_CODE 

RR4:    EVENTCOUNT! 
CP  Re,    #SUCCEEDED 

IF    EC    THEN 

!    DETERMINE    IF   REQUESTED    EVENT 
HAS    OCCURRED    ! 
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039C  54F6 
039E  0004 
03A0  9046 

03A2  5E02 
03A4  0440' 

03A6  5100 
03A8  0000* 


03AA 

6FF1 

03AC 

0008 

03AE 

6FF3 

03B0 

000A 

03B2 

6118 

03B4 

0002' 

03B6 

61F2 

03B8 

0002 

03BA 

61F1 

£3BC 

0000 

03BE 

5414 

03C0 

0000 

03C2 

5D84 

03C4 

0030' 

03C6 

6114 

03C8 

0004 

03CA 

6F84 

03CC 

0034' 

03CE 

6F82 

03D0 

0036' 

03D2 

54F6 

03D4 

0004 

03D6 

5D86 

03DS 

0038' 

03DA 

6181 

03DC 

002C' 

03DE 

6112 

03E0 

0006' 

03E2 

8B62 

03E4 

5E0E 

03E6 

03F4' 

03E8 

6183 

03EA 

0020' 

LDl        RR6,  TEMP.EVENT_VAL(R15) 

CPL    RR6,  RR4 

IF   GT   !EVENT  HAS  NOT  OCCURRED! 
THEN   !BLOCK  PROCESS! 

!  IDENTIFY  PROCESS  ! 

CALL   RUNNING_VP   JRSTURNS: 

Rl:VP  ID 
R3:CPU  #! 

!  SAVE  RETURN  VARIABLES  ! 

LD     TEMP.ID_VP(R15) ,  Rl 

LD  TEMP.CPU_NUM(Rl5) ,    R3 

LD  R8,    A?T.RUNNING_LIST(R1) 

!    RESTORE   REMAINING    ARGUMENTS     ! 
LD  R2,    TEMP. EVENT    NR(R15) 


LD 


Rl,    TEMP. HANDLE    PTR(Rl5) 


!    SAVE    EVENT    DATA    ! 

LDL        P.R4,    HANDLE_VAL.HIGH(R1) 

LDL  APT. AP. HANDLE ( R8 ) ,  RR4 

LD  R4,  HANDLE_VAL.LO'4(Rl) 

LD  APT. AP. HANDLE  [2 J (R8) ,  R4 

LD  A?T.AP.INSTANCE(R8) ,  R2 

LDL  RR6,  TEMP.EVENT_VAL(R15) 

LDL  APT.AP.VALUE(R.e)  ,  RR6 

!  REMOVE  PROCESS  FROM  READY  LIST  ! 
LD     Rl,  APT.AP.AFFINITT(RS) 


ID 


R2,  APT.READY_LIST(R1) 


!  SEE  IF  PROCESS  IS  FIRST 

ENTRY  IN  READY  LIST  ! 
CP     ^2   R8 

IF  EC  VlNSERT  NEW  READY  LIST  HEAL! 
THEN 


LD 


R3,  APT.  AP.  NEXT  AP(R8N' 
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03EC 

6F13, 

03EE 

0006 

03F0 

5E08 

03F2 

040E' 

03F4 

6123 

03F6 

0020' 

03F8 

8B83 

03FA 

5E0E 

03FC 

040A' 

03FE 

6183 

0400 

0020' 

0402 

6F23 

0404 

0020' 

0406 

5E08 

0408 

040E' 

040A 

A132 

040C 

E8F3 

040E 

A182 

0410 

7603 

0412 

000A' 

0414 

7604 

0416 

0020' 

0418 

7605 

041A 

0028' 

041C 

7606 

041E 

002A' 

0420 

2107 

0422 

0002 

0424 

5F00 

0426 

0000* 

0428  61F1 
042 A  0008 
042C  61F3 
042E  000A 

0430  5F00 
0432  0000' 


0434  7604 


LD    APT.READY_LIST(Rl),  R3 

ELSE  !PELETE  FROM  LIST  BODY! 


DO 
ID 


R3,  APT. AP. NEXT  AP ( R2  ) 


CP     R3,  R8 

IF  EC  !FOUND  ITEM  IN  LIST! 
THEN 


LD 
LD 
EXIT 


R3,  APT.AP.NEXT_AP(R8) 
APT. AP. NEXT  AP(R2),  R3 


FI 
LD 
OD 


R2,  R3 


FI 

JTHREAD  PROCESS  IN  PLOCKEE  LIST! 

LD 

LDA 


R2,    R8 

R3t    APT. BLOCKED    LIST 


LDA  R4,    APT.AP.NEXT_AP 

LDA  R5,    APT. AP. PR  I 

LDA  R6,    APT. AP. STATE 

LD  R7,    #ELOCKED 

CALL  LIST_INSERT    !R2:0SJ    ID 

R3:LIST  HEAD  PTR 
R4:NEXT  OBJ  PTR 
Rb:PRIORITY  PTR 
R6:STATE  PTR 
R7: STATS  ! 

!  GET  CURRENT  VP  ID  ! 

LD     Rl,  TEMP. ID  VP(R15) 


LD 


R3,  TEMP. CPU  NUM(R15) 


!  SCHEDULE  FIRST  READY  PROCESS  ! 
CALL   TC  GETWORK   !R1:VP  ID 


!  UNLOCK  APT  ! 
LDA    R4,  APT. LOCK 


R3:CPU  *! 
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0436    45020' 

0438    5E00  CALL      K_UNLOCK 

043A    0000* 

043C  2100 
043E  0002 


!  RESTORE  SUCCESS  CODE  ! 
043C  2100       LD     P.0,  ^SUCCEEDED 


EI 
71 
!  RESTORE  STACK  ! 
0440  010F     ADD    R15,  *SIZEOF  TEMP 
0442  0012 
0*44  9E08     RET 
0446         END  TC  AWAIT 
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0446 


PROCESS  CLASS       PHOCEDU 

T    *|»  *»»  *(•  »|S  5^5  *|5  »,»  Jf*  J(5  3i»  *,*  S|S  5jS  SQC  5»5  J,  J  1,1  5|%  5,5  i,  J  i ,  i  5,5  »i»  *t*  *(*  *i* 

*  READS    SECURITY    ACCESS 

-  CLASS  OF  CURRENT  PROCESS 

*  IN  APT.   CALLED  Ey  SEG 

*  MGR  AND  EVENT  MGR 

sp  sp  sp  ap  sp  ap  ifi  ap  ap  ap  ap  ap  tfi  >$  ^s  ap  ap  ap  5*  ageage  ap  ap  sp  ap  s? 

*  LOCAL   VARIABLES: 

*  Rl :    VP    ID 

*  R5:    PROCESS    ID 


Rl 

apsp 

ap 


apap 


ap 

*,i  »»»  *t»  1*  #",»  5|%  »,C  »j»  i,i  *»»  *|«  ij»  »,t  3|*  «!*  *,*  3BB  *,»  1,5  i,»    J,C  *,i   J,I  iji  ^,1  3|«  *,»  J,» 

J? 
a? 


*  RETURNS: 

*  RR2:    PROCESS    SAC 

*,Z  rt%  », %    *,»  i»»  SgC  *(%  5|*  i>»  5f»  *,C  rti  *,i  1,4  i»»  5fC  i^    »,i  ^1  5ft  J,i  Z^Z   -,*  #)%  J,C  i,S  « 


ENTRY 


0446 

7604 

LDA 

R4, APT. LOCK 

0448 

0000' 

044  A 

5F00 

CALL 

K_L0CK    !R4:~APT.LOCK! 

044C 

0000* 

044E 

5!  00 

CALL 

RUNNING_VP   ! RETURNS: 

0450 

0000* 

Rl:VP  ID 
R3:CPU  U\ 

0452 

6115 

LD 

R5,APT.RUNNING_LIST(R1 ) 

04D4 

0002' 

0456 

5452 

IDL 

RR2, APT.AP.SAC(R5) 

0458 

0024' 

!  UNLOCK  APT 

045A 

7604 

LDA 

R4,  APT. LOCK 

045C 

0000' 

045E 

5F00 

CALL 

K_UNLOCK 

0460 

0000* 

0462 

9E08 

RET 

0464 

END  PROCESS  CLASS 
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0464 


v 

^ 

* 


GET_DBR_NUMBER  PROCEDURE 

-   OBTAINS    DBR    NUMBER    EROM    APT 

*  FOR    THE    CURRENT    PROCESS. 

*  CALLED    Bv    SEGMENT    MANAGER 

*l*  £|»  »,»  5,i  J,i  93  iy*  i*fi  iji  i,I  3,1  ^(1  i^J  »,S  i,i  3,  J  3,*  #^  2,*  J,i  »,I  3,*  V|«  3,»  *,S  *|»  *)*  v,C  »,*  *p*  *|*  *,»  #y* 

*  LOCAL    VARIABLES: 

*  Pi:    VP    ID 

*  R5:    PROCESS    ID 

*  RETURNS:  * 

*  Rl:    DBP    NUMBER  - 


5? 


0464 
046b' 
0468 
046  A 
046C 
046E 


7604- 

0000' 

5E00 

0000* 

5F00 

0000* 


0470  6115 
0472  0002 
0474  6151 
0476    0022 


0478 
047  A 
047C 
047E 
0^-80 
0482 


7604 
0000' 

5F00 

0000* 

9E08 


!N0TE:    DBR    *    IS    ONLY    VALID    WHILE    PROCESS 
IS    LOADED.       THIS    IS    NO   PROBLEM    IN    SASS 
AS    ALL    PROCESSES    REMAIN    LOADED.       IN    A 
MORE    GENERAL    CASE,    THE    DBR    #    COULD    ONLY 
BE   ASSUMED    CORRECT    WHILE    THE    APT    IS    LOCKEIM 

LDA        R4, APT. LOCK 

CALL      K_L0CK       !R4 : ~APT . LOCK ! 

CALL      RUNNING_VP       1RETURNS: 

Rl :VP_ID 
R3:CPU    #! 
LD  R5,APT.RUNNING_LISTfRl^ 

Id  R1,APT.AP.DBR(R5) 

!    UNLOCK    APT    ! 
LDA        R4,    APT. LOCK 

CALL      KJJNLOCK 

RET 
END   GET   DBR    NUMBER 


END    TC 
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APPENDIX  C  -  DISTRIBUTED  MEMORY  MANAGER  LISTINGS 


Z8000ASM   2.02 
LOC     OBJ  CODE 


STMT  SOURCE  STATEMENT 


SIISTON  STTT 

DIST_MM  MODULE 

CONSTANT 

CREATE  CODE 

:  = 

50 

DELETE  CODE 

= 

51 

ACTIVATE  CODE 

;  = 

52 

DEACTIVATE  CODE 

;  = 

53 

SWAP  IN  CODE 

= 

54 

S¥AP^OTJT_CODE 

:  = 

55 

NR  CPTJ 

•  = 

2 

NR  KST  ENTRY 

•  = 

54 

MAX  SEG  SIZE 

:  = 

128 

MAX  DER  NO 

;  = 

4 

KST  SEG~NO 

s 

2 

NR  OF  KSEGS 

:  = 

10 

BLOCK  SIZE 

:  = 

8 

MEM  AVAIL 

s 

%F0fc 

) 

G  AST  LIMIT 

:  = 

10 

INS^ANCEI 

= 

1 

INSTANCE2 

;  = 

2 

INVALID  INSTANCE      : 

;  = 

95 

SUCCEEDED 

;  = 

2 

TYPE 

E  ARRAY 

ARRAY 

[3 

WORD  J 

COM  MSG 

ORAT 

[16 

BYTE  J 

ADDRESS 

WORD 

G  AST  REC 

RECORD 

Thniotte  ID 

LONG 

GLOEAL  ADDR 

ADDRESS 

P  L  ASTE  NO 

WORD 

FLAG 

WORD 

PAR  ASTE 

WORD 

NR  ACTIVE 

WORD 

NO  ACT  DEP 

BYTE 

SIZE1 

BYTE 

PG  TEL 

ADDRESS 

ALIAS  TBL 

ADDRESS 

SEQUENCER 

LONG 

EVENT1 

LONG 

EVENT 2 

LONG 

146 


0000 


0F00 


0000 


0000 


0000 


MM_VP_ID 
SEG    AFRAY 


WORD 
ARRAY    [MAX_SEG_SIZE 


BYTEJ 


$SECTION    D_MM    DATA 
GLOBAL 

MM    CPH    TBL    ARRAY    [NR    CPU    MM    VP    IDJ 


^SECTION   AVAIL  MEM 
INTERNAL 

!    NOTE:    MEM_POOL    IS    LOCATED    IN 
CPU    LOCAL    MEMORY.     ! 
0000  MEM_POOL  ARRAY    [MEM_AVAIL    BYTEJ 


GLOBAL 

!  NOTE:  NEXT 
STUB  AS  AN" 


BLOCK  IS  USED  IN  THE  MM 
OFFSET  POINTER  INTO  THE' 


ALLOCATE 
'ILOCK 


OF  ALLOCATABLE  MEMORY.   IT  IS  INITIALIZED 
IN  BOOTSTRAP  LOADER.  ! 
NEXT_BLOCK       'WORD 
^SECTION  MSG_FRAME_DCL 
INTERNAL 

!NOTE:  THESE  RECORDS  ARE 
TO  DEFINE  MESSAGE  FORMATS 
$A2S  0 
CREATE  MSG       RECORD 


OVERLAYS"  OR  '"FRAMES'"  USED 
.  NO  MEMORY  IS  ALLOCATED  ! 


SABS  0 
DELETE  MSG 


RECORD 


CR 
CE 

ce' 

CE' 
CE' 
CE' 


[DE 
DE' 
DE' 

DE' 


CODE 
>M_HANDL£ 
"ENTRI  NO 
"FILL 
"SIZE 
'CLASS 


CODE 

>M_HANDLF 
'ENTRY_NO 
FILL 


WORD 

H_AP.RAY 

SKORT_INTEG£R 

BYTE 

WORE 

LONG] 


WORD 
H_ARRA¥ 
SEORT_INTEG£R 
A?RA7[7  BYTE  J 


$AES  0 
ACTIVATE 


MSG    RECORD 


[ACT_CODE 
A_DBR_NO 
A~MM  HANDLE 
A  ENTRY_NO 
A_SEGMENT  NO 
A  FILL 


WORE 
WORD 
H  ARRAY 
SHOET_ INTEGER 
SHORT  INTEGER 
LONG] 
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SAES  0 

0000     DEACTIVATE  MSG     RECORD  [DEACT_CODE  WORD 

D_DER_NO  WORD 

D_MM_HANDLE  H_ARRAY 

D^FILL  ARRAY [3  WORD] J 

$ABS  0 

0000     SWAP_IN_MSG       RECORD  TS  IN_COEE  WORD 

SI_MM_HANDLE  H_ARPAT 

SI_DER_NO  WORD 
SI_ACC£SS_AUTE  EYTE 

SI_FILL1  EVTE 

SI_FILL  ARHA3f[2  WCRDJ  J 
$AES  0 

0000     SWAP  OUT  MSG     RECORD  [S  OUT_CODS  WORD 

SO_DER_NO  WORD 

SO  MM  HANDLE  H  ARRAY 


0000 


0000 


0000 


SO_FILL 

ARRAY [3  WORD] J 

SABS  0 

RET_SUC_CODE       RECORD 

EYTE 

SC  FILL 
J 

ARRAY [15  BYTE] 

SAES  0 

R_ACTIVATE_ARG    RECORD 

[R  SUC  CODE 

BVTE 

R  FILL 

BYTE 

R~MM  HANDLE 

H  ARRAY 

R  CLASS 

LONG 

R  SIZE 

WORD 

R'FILLl 

WORT] 

SABS  0 

MM  HANDLE       RECORD 

[ID       LONG 

ENTRV  NO  WORD 

J 
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EXTERNAL 

G_AST_LOCK  WORD 

G_AST      ARRAY [G_AST_L1MIT    G_AST_RECJ 

K_LOCK  PROCEDURE 

K_UNLOCK  •    PROCEDURE 

GET_CPU_NO  PROCEDURE 

SIGNAL  PROCEDURE 

WAIT  PROCEDURE 
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GLOBAL 
$SECTION    D 


MM    PROC 


0000 


0000    030F 
0002    0010 

0004   A1FD 


MM    CREATE    ENTRY 


FROCEDURE 


f     ;,S  J^  2,1  2,1  2,1  2jl  2,1  2,1  2,1  3ifi  2,1  3JC  2^1  3,1  3(1 3J!  2,1  2,1  3^1  3^C  2,1  2,1  3,1  2^  2,1  3|1  2,1  2fC  2^  »,1  2,1  JJ1  2,1 


INTERFACE   BETWEEN    SEG    MGR 
(CREATE_SEG    PROCEDURE  1    AND 
MMGR    PROCESS    ( CREATE_ENTRY 
PROCEDURE).    ARRANGES    AND 
PERFORMS    IPC. 


3|»  2,1  3|1  2,1 3|1  2^1  2,*  2)1  2,1  2,1  3,1  2,1  3fl  2,1  2,1  3^1  2,1  3(1  2,1 3^1  2^1  2,1  2,1  2,1  2,1 3JS  2,1  2^1  2,1  2,1  2,1  2jl 3jl 

*  REGISTER   USE: 

*  PARAMETERS 

*  R0:SUCCESS_CODE    (RET) 
RlthPTR    (INPUT) 
R2:ENTP^    NO    (INPUT) 
R3:SIZE   TlNPUT) 
RR4:CLASS    (INPUT) 

LOCAL   USE 
R6:MM_HAND1E    ARRAY    ENTRY 
R8:~C0M_MSGBUF 
R13:~C0M_MSGBUF 

ENTRY 
!USE    STACK    FOR    MESSAGE! 
SUB        R15,#SIZE0F    COM    MSG 


LD 


R13,R15 


'COM    MSGBUF 


!FILL    COM   MSGBUF    (LOAD    MESSAGE) 
FRAME    IS    BASED    AT    ADDRESS    ZERO 
OVERLAID   ONTO    COM_MSGBUF    FRAME 
EACH    ENTRX    (I.E.    ADDING    TO    EACH    ENTRY)    THE 
BASE   ADDRESS    OF    COM    MSGBUF! 


CREATE   MSG 
IT    IS 
BY    INDEXING 


0006 

4DD5 

LD 

0008 

0000 

000A 

0032 

000C 

3116 

LD 

0£0E 

0000 

0010 

6FD6 

LD 

0012 

0002 

0014 

3116 

LD 

0016 

0002 

0018 

6FD6 

LD 

001A 

0004 

001C 

3116 

LD 

001E 

0004 

0020 

6FD6 

LD 

0022 

0006 

0024 

6FD2 

LD 

LD  CREATE_MSG.CR_C0D£(R13) , #CREATE_CODE 

R6,R1(#0)       JINDET    TO    MM_KANDLE    ENTRY! 
CREATE_MSG.CE_MM_HANDLE[0j  (Rl3),R6 
R6,R1(#2) 

CREATE_MSG.CE_MM_HANDLE[lj  (R13) ,R6 
R6,Rl(#4) 

CREATE_MSG.CE_MM_HANDLE[2J  (R13) , R6 
CREATE    MSG.CE    ENTRY    N0(R13),R2 
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0026  0008 
0028  5DD4 
002A  000C 
002C  6ED3 
002E  000A 
0030  AIDS 
0032  5F00 
0034  018C 

0036  8D06 
0038  60D8 
003A  0000 
003C  010F 
ee3E  0010 
0040  9E08 
0042 


LDL    CREATE_MSG.CE_CLASS (R13) .RB4 

LD  CR£ATE_MSG.CE_SIZE(R13) ,R3 

ID  R8,R13 

CALL      PE*TORM_IPC       ! R8 :    "COM_MSGBUE! 

! RETRIEVE    SUCCESS_CODE    FROM   RETURNED   MESSAGE! 

CLR        R0 

IDB        RL0,RET_SUC_CODE.SUC_CODE(H13) 

ADD        Rl5,#SIZE0F    COM_MSG       ! RESTORE    STACK    STATE! 

RET 
END    MM    CREATE    ENTRY 
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0042 


0042 
0044 
0046 


0048 
004A 
004C 
004E 
0050 
0052 
0054 
0056 
0058 
005A 
005C 
005E 
0060 
0062 
0064 
0066 
0068 
006A 
006C 
006E 

0070 
0072 
0074 
0076 
0078 
007  A 
007C 


030F 
0010 
AlFD 


4DD5 
0000 
0033 
3116 
0000 
6FD6 
0002 
3116 
0002 
6FD6 
0004 
3116 
0004 
6FD6 
0006 
6FD2 
0008 
AIDS 
5F00 
018C 

8D08 
60D8 
0000 
010F 
0010 
9E08 


MM_DELETE_ENTRY  PROCEDURE 

f  ;,si»i  i,s  vi,;  ?,c  ^  i£  :^  v  *i*  ***  *i£^»  *»•  *•-  *»*  *»*  **»»•*  *i:  ***  V  *»*  *i»  *i*  *■*  *r*  *«*  *<*  -w*  *•»  *>* 

*  INTERFACE   BETWEEN    SEG    MGR  * 

*  (DELETE_SEG    PROCEDURE)    AND  * 

*  MMGR    (DELETE_ENTRY    PROCEDURE).- 

*  ARRANGES    AND    PERFORMS    IPC.  * 

*  REGISTER   USE: 

*  PARAMETERS  * 

*  R0:SUCCESS_CODE(RET)  * 

*  Rl:HPTR( INPUT)  * 

*  R2: ENTRY   NO (INPUT)  * 

*  LOCAI    USE  * 

*  R6:MM_EANDLE    ARRAY    ENTRY  * 

*  R8:~C0M_MSGBUF  * 

*  R13:"C0M_MSGBUF  * 

ENTRY 
!USE    STACK    FOR    MESSAGE! 
SUB        R15,#SIZE0F    COM_MSG 

LD  Rl3tRl5         !    ~COM_MSGBUF    ! 

!FILL    COM_MSGBUF    (LOAD    MESSAGE).    DELETE_MSG    FRAME 
IS    BASED   AT   ADDRESS    ZERO.    IT    IS    OVERLAID    ONTO 
COM   MSGBUT    F^AME    BY    INDEXING    EACH    ENTRY    (I.E.    ADD- 
ING  TO    EACH    ENTRY)    THE    BASE   ADDRESS    OF    COM    MSGEUF! 


LD  DELFTE_MSG.DE_C0DE(R13^ ,#LELETE_CODE 

LD  R6,Rl(#fc)       JINDEX    TO    MM_HANDLE   ENTRY! 

LD  LELETE_MSG.DE_MM_HANDLE[0j  (R13),R6 

LD  R6,R1(#2) 

LD  DELETE_MSG.DE_MM_HANDLE[lJ  (R13) ,R6 

LD  R6,P1(#4) 

LD  DELETE_MSG.DE_MM_HANDLE[2J  (R13),E6 

LD  DELETE    MSG.DE    ENTRY    N0(R13),R2 


LD  R8.R13 

CALL      PERFORM_IPC       !R6:    ~COM_MSGIUF! 

JRETRIEVE    SUCCESS_CODE    FROM   RETURNED   MESSAGE! 

CLR        R0 

LDB         RL0tRET_SUC_CODE .SUC_C0DE(R13^ 

ADD        R15,#SIZE0F    COM_MSG       !RESTORE    STACK    STATE! 

RET 
END    MM    DELETE    ENTRY 
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007  C 


MM   ACTIVATE  PROCEDURE 

*  INTERFACE    BETWEEN    SEG    MGR  - 

*  (MAKE  KNOWN    PROCEDURE)    ANT  * 

*  *MGR         (ACTIVATE    PROCEDURE).  - 

*  ARRANGES    AND    PERFORMS    IPC.  v 


5P 
J? 


V 

REGISTER   USE: 

;l* 

PARAMETERS 

* 

Rl  :DBR   NO(INPUT) 

* 

R2: HPT? (INPUT) 

W 

R3:ENTRY   NO 

-"? 

R4:SEGMENT    NO 

V 

R12:RET   HANDLE    PTR 

n* 

LOCAL   USE 

V 

R8:~C0M    MSGBUF 

* 

R13:~C0M    MSGBUF 

V 

RETURNS: 

T« 

R0:SUCCESS    CODE 

V 

RR2:CLASS 

*l~ 

R4:SIZE 

007C  030F 
007E  0010 
0080    A1FD 


0082   93FC 


0084 

4DD5 

ID 

0086 

0000 

0088 

0034 

008A 

6FD1 

LD 

008C 

0002 

008E 

3126 

LD 

0090 

0000 

0092 

6FD6 

LD 

0094 

0004 

0096 

3126 

LD 

0098 

0002 

009A 

6FD6 

LD 

009C 

0006 

009E 

3126 

LD 

00A0 

0004 

00A2 

6FD6 

LD 

ENTRV 
!USE    STACK    FOR   MESSAGE! 
SUB        R15,#SIZE0F    COM_MSG 

LD  R13.R15         !    "COM_MSGBUF    ! 

!    SAVE    RETURN    HANDLE    POINTER    ! 
PUSH      0R15,    R12 

!FILL    COM_MSGBUF    (LOAD    MESSAGE).    ACTIVATE_MSG    FRAME 
IS    BASED    AT   ADDRESS    ZERO.    IT    IS    OVERLAID    ONTO 
COM  MSGBU1'    FRAME    BY    INDEXING    EACH    ENTRy    (I.E.    ADD- 
ING  TO    EACH    ENTRK )    THE    BASE   ADDRESS    OF    C0M_MSG2UF! 
ACTIVATE   MSG.ACT    C0DE(R12) , #ACTIVATE    CODE 


ACTIVATS_MSG.A_DBR_N0(R13) ,R1 
R6tR2(#0) 

ACTIVATE_MSG.A_MM_HANDLE[^J  (E 13 ) ,R6 
R6,R2(#2) 

ACTIVATE_MSG.A_MM_HANDLS[1J  (R13)  ,R6 
R6,R2(#4) 
ACTIVATE_MSG.A_MM_HANDLS[2J (R13) ,R6 


153 


e£A4 

0008 

00A6 

6EDB 

00A8 

000A 

£0AA 

6Erc 

00AC 

000B 

00AE 

AiDe 

0eB0 

5F00 

00B2 

018C' 

0£B4  97FC 


00  B6 

e0B8 

00BA 
00BC 
00BE 
tf0C0 
00C2 
?£C4 


54Db 
20tf2 
5DC6 
0000 
61D6 
0006 

0004 


00C6  8D08 
fe?eC8  60D8 
tf0CA  0000 
00CC    54D2 

00CE  e0es 

00D0  61D4 
00D2  000C 
00D4  01£F 
00D6  0010 
00D8  9E08 
£0DA      END 


LDB    ACTIVATE_MSG.A_ENTRY_N0(R13) ,EI3 

LDB    ACTIVATE_MSG.A_S2GMENT_NG(R13 ) ,RL4 

LD     R8,R13 

CALL   tfEBFORM^IPC  ! (R8  :"COM_MSG£UF ! 

!  RESTORE  RETURN  HANDLE  POINTER  ! 
POP    R12,  0R15 

!  UPDATE  MM  HANDLE  ENTRY  ! 

LDL    RR6,  R_ACTIVATE_ARG.R_MM_HANDLE(R13) 

LDL   MM_EANDLE.ID(R12) ,  RR6 

LD  R6tR_ACTIVATE_ARG.R_v,M_HANDLEl2J  fR13) 

ID  MM_EANDLE.ENTRY_N0(R12) ,    R6 

! RETRIEVE  OTHER  RETURN  ARGUMENTS! 

CL*    R0 

LDB    RL0,R_ACTIVATE_A3G.R_SUC_CODE(R13) 

LDL 

LD 

ADD 


RR2,R_ACTIVATE_ARG.R_CLASS(R13) 
R4,R_ACT1VATE_ARG.R_SIZE(R13) 
R15,#SIZE0F  COM  MSG  !RESTORE  STACK  STATE! 


RET 

MM  ACTIVATE 
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00DA        MM  DEACTIVATE  FROCEEURE 

588  INTERFACE  BETWEEN  SEG  MGR  - 

*  (TERMINATE  PROCEDURE)  AND  * 

*  MMGR  (DEACTIVATE  PROCEDURE).  * 

*  ARRANGES  AND  PERFORMS  IPC. 

jjc  J?  sjs  jpjje  jjc  a*  sje  jjc  *f  sjc  ajs  >*  sp  sje  jjc  sa:  j*  apajc  ^e  ape  a?  3?  sp  age  ap  jfc  ap  ap  ap  ap  ap 

*  REGISTER   USE:  * 

-  PARAMETERS  - 

*  R0:SUCCESS_CODE(RET,I  - 

*  RlrDBR  NO(INPUT)  * 

-  R2:HPTR(INPUT)  - 

*  LOCAL  USE  * 

*  R6:MM   HANDLE   ARRAY    ENTRY  * 

-  R8:~C0M_MSGEUF  * 

*  R13:~C0M_MSGEUF  * 

apapapapapap^ap^apapjpapapapapapapapapapapapapapajCapapapSpapapap  J 

ENTRY 
!USE  STACK  FOR  MESSAGE! 
00DA   030F  SUB        R15,#SIZE0E   C0M_MSG 

00DC    0010 
00EE  A1FE     LD     R13.R1S    !  ~COM_MSGEUF  ! 

!FILL    COM_MSGEUF    (LOAD   MESSAGE).    DEACTIVATE   MSG   FRAME 
IS  EASED  AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM_MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD- 
ING TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM_MSGBUF! 

00E0  4DD5     LD     DEACTIVATE_MSC .DEACT_CODE ( R13 ^, 

00E2  0000  #DEACTIVATE_COEF 

00E4  0035 

00E6  6FD1     LD     EEACTIVATE_MSG. D_DBR_NO (R13 ) . Rl 

00E8  0002 

00EA  3126     LD     Rb,P.2(#0)   !  INDEX  TO  MM  HANDLE  ENTRV! 

00EC  0000 

00EE   6FD6  LD  DEACTIVATE   MS G. D_MM_HANELE [0j  (R13) ,R6 

00F0    0004 

00F2    3126  LD  R6,R2(#2) 

00F4    0002 

00F6   6FD6  LD  DEACTIVATE   MSG.D_MM  HANDL£[l J (R13) fR6 

00Fe    0006 

00FA    3126  LD  R6,P2(#4) 

00FC    0004 

00FE    6FD6  LD  DEACTIVATE   MS  CD    MM_HANDLE  [2j  (  Rl  3)  ,  R6 

0100    0008 

0102  A1D8     LD     R8,R13 

0104    5F00  CALL      PERFORM_IPC       !R8:    ~CQM_MSG.cUF ! 

0106    018C' 


155 


IF.JSTRIEVE  SUCCESS  CODE  FROM  RETURNED  MESSAGE! 


01£8    8D08 

i?lfeJA    60D8 

010C  0000 

010E  010F 

0110  0010 

0112  9E08     RET 

0114      END  MM  DEACTIVATE 


CLR    R0 

LDB    RI0,PET_SUC_CODE.SUC_COEE(R12> 

ADD    R15,#SIZE0F  COM  MSG-  {RESTORE  STACK  STATE! 
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0114         MM  SWAP  IN  PROCEDURE 

*  INTERFACE  BETWEEN  SEG  MGR  (SM_* 
-  SWAP  IN  PROCEDURE)  AND  MMC-R    * 

*  (SWAP  IN  PROCEDURE).  ARRANGES  * 

*  AND  PERFOPMS  IPC  . 

*  REGISTER  USE:  * 

*  PARAMETERS  - 

*  R0:SUCCESS_CODS(RET)  * 

*  Rl :EEK_N0( INPUT)  * 

*  R2:HPTR( INPUT)  * 

*  R3: ACCESS      (INPUT)  - 

*  LOCAL  USE  * 

*  R6:MM_RANDLE  ARRAY  ENTRY      * 

*  R8:~C0M_MSGEUF  - 

*  R13:~CCM_MSGEUF  * 

ENTRT 

!USE  STACK  FOR  MESSAGE! 
0114  030F     SUB    R15,#SIZEOF  COM_MSG 
0116  0010 
0118  A1FD     LD     R13.R15    !  ~COM_MSGBUF  ! 

.'FILL  COM_MSGEUF  (LOAD  MESSAGE).  SWAP  IN  MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM_^SGBUF  FRAME  EY  INDEXING  EACH  ENTRY  (I.E.  ADD- 
ING TO  EACH  ENTRT)  THE  BASE  ADDRESS  OF  COM_MSGBUF! 

011A  4DD5     ID  SWAP  IN  MSG.S  IN  C0DE(R13) ,#SWAP_IN  CODE 

011C  0000 

011E  0036 

0120  3126     LD     R6,R2(#0)   'INDEX  TO  MM  HANDLE  ENTRT! 

0122  0000 

0124  6FD6     LD    SWAP  IN_MSG.SI_MM  HANDLE [0] ( R13) ,R6 

0126  0002 

0128  3126     LD     R6,?2(#2) 

012A  0002 

012C  6FD6     LD     SWAP  IN_MSG.SI  MM  HANDLE  [lj  ( R13> ,R6 

012E  0004 

0130  3126     LD     R6,R2(#4) 

0132  0004 

0134   6FD6  LD  SWAP_IN    MSG .S I_MM_EANDLE  [2J  (R13 )  ,R6 

0136    0006 

0138  6FD1     LD     SWAP_IN_MSG .SI  DER_NO( R13) ,R1 

013A  0008 

013C  6FDB     LDB    SWAP_IN_MSG .S I_ACCESS_AUTH (R13) , RL3 

013E  000A 

0140  UD8     LD     R6,P13 

0142  5F00     CALL   PERFORM  IPC   !R8:  ~COM_MSGSUF' 

0144  013C' 
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JRETRIEVE    SUCCESS    CODE    FROM   RETURNEE   MESSAGE! 

0146    8D08  CLR        Re 

0148    60D8  IDB         RL0 ,RET_SUC_CODE .SUC_COEE (R13 ) 
014A    0000 

014C    010F  ADD        R15,#SIZE0F    COM_MSG    !RESTORE    STACK    STATE! 
014E    0010 

0150    9E08  RET 

0152  END  MM   SWAP    IN 
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0152  MM   SWAP  OUT  PROCEDURE 

f  -,*  »>»  i*  *i*  *1*  «|*  *t%  **»  *,-  9|*  ?,*  *j£  -,*  *,*  5|*  i,»  J,*  #|*  *,»  *,«  J, I  *(«  «,*  *»*  5,5  J,S  *,"  i|S  *,£  i,l  3|*  f|*  -,* 

*  INTERFACE  BETWEEN  SEG  YGR  (SM_* 

*  SWAP  OUT  PROCEDURE)  AND  MMGR   * 

*  (SWAF_OUT  PROCEDURE).  ARRANGES* 

*  AND  PERFORMS  IPC.  * 

sp »?  sp  ;p  sp  ape  v  Tjt  >je  ageafcagt  sp  a?  sp  sp  sp  sp  sp  sp  sp  sp  »?  s?  sp  sp  t?  jjc  sp  sp  sp  sp  sp 

*  REGISTER   USE:  - 

*  PARAMETERS  * 

*  R0:SUCCESS_CODE(RET)         * 

*  RlrDBR   NO(INPUT)  * 

*  R2:HPTR( INPUT)  * 

*  LOCAL  USE  * 
"      R6:MM_HANDLE  ARRAY  ENTRY      * 

*  R8:~G0M   MSGBUI  * 

*  R13:~C0M_MSGBUF  * 

ENTRY 
!USE  STACK  FOR  MESSAGE! 
0152  030F     SUB    R15,#SIZE0F  COM_MSG 
0154  0010 
0156  AlFD     LD     Rl3,Rl5    !  ~COM_MSGBUF  ! 

'.FILL  COM  MSGBUE  (LOAD  MESSAGE).  SWAP  OUT_MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM  MSGBUE  FFA*E  BT  INDEXING  EACH  ENTRY  (I.E.  ADD- 
ING TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  CCM_MSGBUF! 

0158  4DD5     LD     SWAP_OUT_MSG.S_OUT_CODE (R13 ) ,  #SWAP_OUT_CODE 

015A  0000 

015C  0037 

015E  3126     LD     R6,R2(#0)   .'INDEX  TO  MM_flANDLE  ENTRY! 

0160  0000 

0162   6FD6  LD  SWAP    OUT    MSG. S O_MM_HANDL£[0j  (R13 ) ,R6 

0164  0004 

016b  3126     LD     R6,R2(#2) 

0168  0002 

016A   6FD6  LD  SWAP   OUT   MSG.SO    MM_HANDLE[1J  (R13) ,R6 

016C  0006 

016E  3126     LD     R6,R2(#4) 

0170  0004 

0172  6FD6     LD     SWAP_OUT  MSG .SO  MM  HANDLE [2J  (R13 ) ,R6 

0174  0008 

0176  6FD1     LD     SWAP_OUT_MSG.SO_D£R_NO (R13 ) ,R1 

0178  0002 

017A  A1D8     LD     R8,R13 

017C  5F00     CALL   PERFORM_IPC   !R8:  ~COM_MSG£UF ! 

017E  018C' 
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JRETRIEVE   SUCCESS_CODE    FROM    RETURNED   MESSAGE! 

0180   8D08  CLR        R0 

0182   S0D8  LDB        RL0 , RET    SUC    CODE .SUC_CODE (R13 ) 
0184    0000 

0186    010F  ADD        Rl5t#SIZEOE    COM_MSG    {RESTORE    STACK    STATE! 
0188    0010 

018A   9E08  RET 

018C  END  MM    SWAP    OUT 
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eiac 


PERFORM  IPC  PROCEEDS* 

*  SERVICE  ROUTINE  TO  ARRANGE  AND     * 

*  PERFORM  IPC  WITH  THE  MEM  MGR  PROC  * 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  R8:  ~COM_MSG(INPUT)  * 

*  LOCAL  USE  * 
R1.R2:  WORK  REGS  * 
R4:  "G_AST_LOCK  * 
R13:  ~COM_MSG£UF  * 


018C 
018E 
0190 

0192 
ei94 

0196 
0198 
019A 
019C 
019E 
01A0 
01A2 
01A4 
01A6 
01A8 
01AA 

eiAC 

01AE 
01B0 
01B2 
01B4 
01B6 
ei£8 
01BA 


93FD 

5F00 

0000* 

A112 

6121 

0000' 

7504 

0000* 

51*00 

0000* 
5F00 

0000* 

97FD 

A1D8 

93FD 

5F00 

0000* 

7504 

0000* 

5F00 

0000* 

97FD 
9E08 


ENTRV 

PUSH  0R15.R13       !"COM    MSGBUF! 

CALL  GET_CPU_NO    !RETZR1 :CPU_NO ! 

£jj  p2    pi 

LC  Rl!MM_CPU_TBL(R2)       !MM_YP_ID! 

LDA  R4,G_AST_LOCK 

CALL  K_LOC£ 

CALL  SIGNAL       ! Rl :MM_VP_ ID ,RS :~COM_MSGPUF ! 

POP  R13.PR15 

LD  R8.R13       !~COM    MSGBUF! 

PUSH  PR15.R13 

CALL  WAIT   !R8:"C0M_MSGBUF! 

LDA  R4,G_AST_LOC* 

CALL  K_UNLOCK 

POP  R13.0R15 

RET 


END  PERFORM  IPC 
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01BA         MM_ALLCCATE       PROCEDURE 

*  ALLOCATES  BLOCKS  OF  CPU* 

*  LOCAL  MEMORY.   EACH  * 

*  BLOCK  CONTAINS  256  * 

*  BYTES  OF  MEMORY.  * 

*  PARAMETERS:  * 

*  R3:  #  OF  BLOCKS       * 

*  RETURNS:  * 

*  R2:  STARTING  ADDR      * 

*  LOCAL:  * 

*  R4:  BLOCK  POINTER      * 

ENTRf 

!  NOTE:  THIS  PROCEDURE  IS  ONLY  A  STUB 
OF  THE  ORIGINALLY  DESIGNED  MEMORY 
ALLOCATING  MECHANISM.   IT  IS  USED 
BY  tee  PROCESS  MANAGEMENT  DEMONSTRATION 
TO  ALLOCATE  CPU  LOCAL  MEMO?. I  FOR  ALL 
MEMORY  ALLOCATION  REQUIREMENTS.  IN  AN 
ACTUAL  SASS  ENVIRONMENT,  THIS  WOULD 
BE  EETTER  SERVED  TO  HAVE  SEPARATE 
ALLOCATION  PROCEDURES  FOR  KERNEL  AND 
SUPERVISOR  NEEDS.  (E.G.,  KERNEL  ALLOCATE 
AND  SUPERVISOR  ALLOCATE),  ! 

!  COMPUTE  SIZE  OF  MEMORY  REQUESTED  ! 

SLL    P3,  #BLOCK_SIZE 

!  COMPUTE  OFFSET  OF  MEMORY  THAT  IS 

TO  BE  ALLOCATED  ! 
LD      R4,  NEXT_BLOCK   10FFSET! 

LDA     R2,  MEM_P00L(R4)  ISTART  ADDR! 

ADD     R4,  R3   JUPDATE  OFFSET! 
!  UPDATE  OFFSET  IN  SECTION  OF  AVAILABLE 
MEMORY  TO  INDICATE  THAT  CURRENTLY 
REQUESTED  MEMORY  IS  NOW  ALLOCATED  ! 
01C8  6F04     LD      NEXT_BLOCK ,  R4   !SAVE  OFFSET! 
01CA  0F00' 
01CC  9E08     RET 
01CE         END  MM  ALLOCATE 


01BA 

B331 

01BC 

0006 

01BE 

6104 

01C0 

0F00 

01C2 

7642 

01C4 

0000 

eice 

8134 
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eiCE 


MM  TICKET  PROCEDURE 


01CE  93F1 


01D0 
01D2 
01D4 
01D6 


7604 
0000* 
5F00 
0000* 


01D6  97F1 


01DA 
01DC 

01DE 
01E0 


6118 
02  04 

5466 
0014* 


01E2  9464 


01E4  1606 
01E6  0000 
01E8  0001 

01EA  5D66 
01EC  0014* 


01EE 
01F0 
01F2 
01F4 
01F6 


91F4 

7604 

0000* 

5F00 

0000* 


01F8  95F4 
01FA  9E08 
01FC 


*  RETURNS  CURRENT  VALUE  OF 

*  SEGMENT  SEQUENCER  AND 


*  INCREMENTS  SEQUENCER  VALUE* 

*  FOR    NEXT    TICKET    OPERATION    * 

^  ^  **  *  3*  «  >p  jgc  2?  *  *:  sgc  j«c  sp  *c  ;ge  *c  ?  jp  J?  ip  sgc  3?  :p  3*  4(  j«c  J*  *c 

*  PARAMETERS:  * 

*  11:    SEG   HANDLE    PTR  * 

RETURNS:  * 

RR4:    TICKET    VALUE  * 

LOCAL    VARIABLES:  * 

RR6:    SEQUENCER    VALUE  * 

R8:    G_AST    ENTRY    #  * 

ENTRY 
!  SAVE  HANDLE  PTR  ! 
PUSH  (?R15,    Rl 

!  LOCK  G_AST  ! 
LDA    R4,  G_AST_LOCK 

CALL      K_LOCK 

!    RESTORE    HANDLE    PTR    ! 

POP        Rl,    G>R15 

!    GET    G_AST    ENTRY   #    ! 

LD  Re,    MM_RANDLE.ENTRY_NO(Rl) 

!    GET    TICKET    VALUE    ! 

LDL        RR6,    G_AST.SEGUENCER(R8) 

!  SET  RETURN  REGISTER  VALUE  ! 
LDL    RR4,  RR6 
!ADVANCE  SEQUENCER  FOR  NEXT 
TICKET  OPERATION! 
ADDL   RR6,  #1 


!  SAVE  NEW  SEQUENCER  VALUE  IN  G_AST  ! 
IDL        G_AST. SEQUENCER* Re),    RR6 

!  UNLOCK  G_AST  ! 

!  SAVE  RETURN  VALUES  ! 

PUSHL   <?R15,    RR4 

LDA    R4,  G_AST_LOCK 

CALL      K_UNLOCK 

!  RETRIEVE  RETURN  VALUES  ! 
POPL   RR4,  PR15 
RET 
END   MM  TICKET 
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01FC 


MM_READ_EVENTCOUNT  PROCEDURE 

*  READS    CURRENT    VALUE    OF   THE      * 

*  EVENTCOUNT   SPECIFIED    BY    THE   * 

*  USER.  * 

*  PARAMETERS:  * 

*  Rl:    SEG   HANDLE    PTR  * 

*  R2:    INSTANCE    (EVENT   #)  • 

*  RETURNS:  * 

*  RR4:    EVENTCOUNT   VALUE  * 

:p  ^  *  3C*<  3*  *c  *c  *c  3C  *  *c  >P  *  *c  *c  *(  3?  *c  *e  >*  *  7  *c  *  *  3«C  >P  *  «  9 


*  LOCAL    VARIABLES: 

*  RR6:  SEQUENCER  VALUE 


*      R8:    G_AST    ENTRY   #  * 


01FC  93F1 
01FE  93F2 

0200  7604 
0202  0000* 
0204  5F00 
0206  0000s" 

0208  97F2 
020A  97F1 

020C  6118 
020E  0004 


0210 

0B02 

0212 

0001 

0214 

5E0E 

0216 

0224' 

0218 

5484 

021A 

0018* 

021C 

2100 

021E 

0002 

0220 

5E08 

0222 

023C' 

0224 

0E02 

0226 

0002 

0228 

5E0E 

022A 

0238' 

022C 

5484 

"^NTRY 
!  SAVE  INPUT  PARAMETERS  ! 
PUSH      GR15,    Rl 
PUSH      PR15,    R2 
!  LOCK  G_AST  ! 
LDA    R4T  G_AST_L0CK 

CALL      K_L0CK 

!  RESTORE  INPUT  PARAMETERS  ! 

POP    R2,  0R15 

POP        Rl,    GR15 

!  GET  G_AST  ENTRY  #  ! 

LD     R8,  MM_HANDLE.ENTRY_N0(R1) 

!  READ  EVENTCOUNT  ! 
!  CHECK  WHICH  EVENT  #  ! 
IF   R2 
CASE   #INSTANCE1  THEN 


LDL    RR4,  G_AST.EVENTl(R8) 
LD  R0,    #SUCCEED£D 

CASE   #INSTANCE2  TEEN 


LDL    RR4,  G  AST. EVENT2 (R8 ) 
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022E  001C* 
0230  2100 
0232  0002 
0234  5E08 
0236  023C' 
0238  2100 
023A  005F 


023C  91F4 

023E  7604 
e240  0000* 
0242  5F00 
0244  0000* 

0246  95F4 
0248  9E08 
024A 


LD     R0,  #SUCCEEDED 

ELSE   !INVALID  INPUT! 

LD     R0t  #INVALID_INSTANCE 

FI 

!    NOTE:    NO    VALUE    IS    RETURNED    IF 

USER    SPECIFIED    INVALID    EVENT    # 
!    SAVE    RETURN    VALUES     I 
PUSHL    (?R15,    RR4 
!    UNLOCK    G_AST    ! 
LDA        R4f    G_AST_LOCK 

CALL      KJJNLOCK 

!    RESTORE   RETURN    VALUES    ! 
POPL      RR4,    0R15 
RET 
END      MM    READ   EVENTCOUNT 


165 


024A 


MM   ADVANCE 


PROCEDURE 


I  K*&>*  Wi«>PWWWWW  ?^>»9irV9W^W?Vs;ip 


*  DETERMINES    G_AST    OFFSET    FROM  * 

*  SEGMENT   HANDLE   AND    INCREMENTS         * 

*  THE    INSTANCE(EVSNT    #)    SPECIFIED   * 

*  BY   TEE   CALLER.      THIS    IN   EFFECT 

*  ANNOUNCES    THE   OCCURRENCE    OF    THE 

*  EVENT.      THE    NEW    VALUE    CF    THE 

*  EVENTCOUNT    IS    RETURNED   TO    THE 

*  CALLER. 

*  PARAMETERS:  * 

*  Pi:    HANDLE    POINTER  * 

*  R2:    INSTANCE    (EVENT    #) 

*  RETURNS:  * 

*  RR2:    NEW   EVENTCOUNT    VALUE  * 


024A 

93F1 

024C 

93F2 

024E 

7604 

0250 

0000* 

0252 

5F00 

0254 

0000"' 

025b 

97F2 

0258 

97F1 

025A 

6114 

025C 

0004 

025E 

0B02 

0260 

0001 

0262 

5E0E 

0264 

027C' 

0266 

5442 

0268 

0018* 

026A 

1602 

026C 

0000 

026E 

0001 

0270 

5D42 

0272 

0018* 

0274 

2100 

0276 

0002 

0278 

5E08 

ENTRT 
!    SAVE    INPUT    PARAMETERS     ! 
PUSH      GR15,    Rl 
PUSH      GR15,    R2 
!    LOCK   G  AST    ! 
LDA        R47    G_AST_LOCK 

CALL      K_L0CK 

!    RESTORE    INPUT    PARAMETERS    ! 

POP        R2,    PR15 

POP        Rl,    0R15 

!    GET   G_AST   OFFSET    ! 

LD  R4,    MM_HANDLE.£NTRT_NO(Rl) 

!    DETERMINE    INSTANCE    ! 
IF      R2 
CASE      #INSTANCE1      THEN 


LDL        RR2,    G_AST.EVENT1(R4) 
ADDL      RR2,    #1 

!    SAVE    NEW    EVENTCOUNT    ! 

LDL        G_AST.EVENT1(R4),    RR2 

LD  R0,    #SUCCESDED 

CASE      #INSTANCE2      THEN 
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027A 

029E' 

027  C 

0E02 

027E 

0002 

0260 

5E0E 

0282 

029A' 

0284 

5442 

LDL 

RR2,    G_AST.EVENT2(R4) 

0286 

001C* 

0288 

1602 

ADDL 

RR2,    #1 

028A 

0000 

028C 

0001 

!    SAVE    NEW    EVENTCOUNT 

028E 

5D42 

LDL 

G_AST.EVSNT2(R4) ,    RR2 

0290 

001C* 

0292 

2100 

LD 

R0,    #SUCCEEDED 

0294 

0002 

0296 

5E08 

ELSE 

IINVALID    INPUT! 

0298 

029E' 

029A 

2100 

LD 

R0,    #INVALID_INSTANCE 

029C 

005F 

029E  7604 
02A0  0000* 
02A2  5F00 
02A4  0000* 
02A6  9E08 
02A8 


FI 

!  NOTE:  AN  INVALID  INSTANCE  VALUE 

WILL  NOT  AFFECT  EVENT  DATA  ! 
!  UNLOCK  G  AST  ! 
LDA    R4,  G_AST_LOCK 

CALL   K_UNLOCK 

PET 
END  MM_ADVANCE 
END  DIST  MM 
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APPENDIX  D  -  GATE  KEEPER  LISTINGS 


Z8000ASM   2.02 
LOC     OBJ  CODE 


STMT  SOURCE  STATEMENT 
KERNEL_GATE_KEEPER       MODULE 
$LISTON  $TTT 


constant 
advance_call 
awai?_call 
creats_seg  call 
delete_seg!call 

MAKE_KNOWN_CALL 

READ_CALL 

S^_SWAP_IN  CALL 

?M_SWAP  OUT_CALL 

TERMINATE_CALL 

TICKET_CALL 

WRITE_CALL 

WRITELN_CALL 

CRLF_CALL 

W^ITE 

WRITSLN 

CRIF 

MONITOR 

REGISTER_BLOCK 

TRAP_CODE_OFFSET 

INVALID  KERNEL  ENTRY 


1 
2 
3 
4 

5 
6 
? 

8 

y 

10 

n 

12 
13 

S0FC8 

*0FC0 

*eFD4 

2A902 

32 

36 

%BAD 


PRINT 
PRINT 


CHAR! 
MSG! 


CAR  RET /LINE  FEED! 


GLOBAL 

GAT£_KEEPEP_ENTRY 

LA*  EL 

EXTERNAL 

ADVANCE 

PROCEDURE 

AWAIT 

PROCEDURE 

CREATE  SEG 

PROCEDURE 

DELETE  SEG 

PROCEDURE 

MAKE  KNOWN 

PROCEDURE 

READ 

PROCEDURE 

SM  SWAP  IN 

PROCEDURE 

SM~SWAP_OUT 

PROCEDURE 

TERMINATE 

PROCEDURE 

TICKET 

PROCEDURE 

KERNEL_EXIT 

LABEL 

INTERNAL 

$SECTION  KERNEL  GATE 

FROC 
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emu 


GATE  KEEPER  MAIN 


PROCEDURE 


0000  030F 
0002  0020 
0004  1CF9 
0006  010F 

0008  93F2 
000A  7D27 

000C  2DF2 

000E  93F2 

0010  31F2 
0012  0024 


0014  8C28 


0016 

0B02 

0018 

0001 

001A 

5E0E 

001C 

0028' 

001E 

97F2 

0020 

5F00 

0022 

0000s* 

0024 

5E08 

0026 

010C' 

0028 

0B02 

002A 

0002 

002C 

5E0E 

0£2E 

003A' 

0030 

97F2 

0032 

5F00 

e034 

0000* 

0036 

5E08 

0038 

010C' 

003A 

0B02 

003C 

0003 

003E 

5E0E 

fc?e40 

004C' 

ENT?Y 

GATE  KEEPER  ENTRY : 

!  SAVE  REGISTERS  ! 

SUB    R15,  #REGIST^R_BLOCX 


LDM 


@R15,  Rl,  #16 


!  SAVE  NSP  ! 

PUSH   G>R15,  R2 

LDCTL  R2,  NSP 

!  RESTORE  INPUT  REGISTERS  ! 

EX     R2,  CR15 

!  SAVE  REGISTER  2  ! 

PUSH      G>Rl5f    R2 

!  GET  SYSTEM  TRAP  CODE  ! 

LD     R2,  R15(ffTRAP_C0DE_0FFSET) 

!  REMOVE  SYSTEM  CALL  IDENTIFIER  FROM 

SYSTEM  TRAP  INSTRUCTION  ! 
CLRB   RH2 
!  NOTE:  THIS  LEAVES  THE  USER  VISI3LE 

EXTENDED  INSTRUCTION  NUMBER  IN  R2  ! 
!  DECODE  AND  EXECUTE  EXTENDED  INSTRUCTION 
IF   R2 
!  NOTE:  THE  INITIAL  VALUE  FOR  REGISTER  2 

WILL  BE  RESTORED  WHEN  THE  APPROPRIATE 

CONDITION  IS  FOUND  ! 
CASE   #ADVANCE  CALL   THEN 


POP    R2?  GR15 
CALL   ADVANCE 

CASE   #AVAIT  CALL   THEN 


POP    R2,  GR15 
CALL   AWAIT 

CASE   #CREATE  SEG  CALL   THEN 
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0042  97F2        POP    E2,  0R15 

0044  5F00        CALL   CREATi_SEG- 

0046  0000* 

0046  5E08      CASS   #DELETE  SEG  CALL   THEN 

004A  010C' 

004C  0B02 

0e4E  0004 

0050  5E0E 

0052  005E' 

0054  97F2        POP    R2,  0R15 

0056  5F00       CAIL   DELETE_SEG 

0058  0000* 

0e5A    5208  CASE      #MAK2_KN0WN_CALL      THEN 

005C  010C' 

005E  0B02 

0060  0005 

0062  5E0E 

0064  0070' 

0066  97F2        POP    R2,  (?R15 

0068  5F00       CALL   MAKE_KNOVN 

006A  0000- 

006C  5E08      CASE   #READ  CALL   THEN 

006E  010C' 

0070  0E02 

0072  0006 

0074  5E0E 

0076  0082' 

0078  97F2       POP    R2,  CR15 

007A  5F00        CALL   READ 

007C  0000- 

007E  5E08      CASE   #SM  SWAP  IN_CALL   THEN 

0080  010C' 

0082  0B02 

0084  0007 

0086  5E0E 

0088  0094' 

008A  97F2       POP    R2,  0R15 

008C  5F00        CAIL   SM  SWAP  IN 

008E  0000* 

0090  5E08      CASE   #SM  SWAP_OUT_CALL   THEN 

0092  010C' 

0094  0E02 

0096  0008 

0098  5E0E 

009A  00A6' 

009C  97F2       POP    ?.2,  C°R15 

009E  5F00       CALL   SM_SWAP_OUT 

00A0  0000* 

00A2  5E08      CASE   ^TERMINATE  CALL   THEN 

00A4  010C' 

00A6  0B02 
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06?  AS 
00AA 
00AC 
£0  AE 
00B0 
00B2 
00  £4 
00B6 
0038 
fc?0BA 
00BC 
00BE 
0CC0 
00C2 
00C4 
0eC6 
00C8 
00CA 
00CC 
00CE 
00D0 
00D2 
00D4 
00D6 
00D8 
00DA 
00DC 
00DE 
00E0 
00E2 
e0E4 
00E6 
00E8 
00EA 
00EC 
00EE 
00F0 
00F2 
00F4 
00F6 
00F9 
00FA 
0ZFC 
00FE 


0009 

5E0E 

00B8' 

97F2 

5F00 

0000* 

5E08 

010C' 

0B02 

000A 

5E0E 

00CA' 

97F2 

5F00 

0000V 

5E08 

010C' 

0B02 

000B 

5E0E 

00DC' 

97F2 

5F00 

0FC8 

5E08 

010C' 

0B02 

000C 

5E0E 

00EE' 

9'7F2 

5F00 

0FC0 

5E08 

010C  ' 

0P02 

000D 

5E0E 

0100' 

97F2 

5F00 

0FD4 

5E08 

010C' 


POP    R2,  GRlb 
CALL   TERMINATE 

CASE   ^TICKET  CALL   THEN 


POP    R2,  0R15 

CALL   TICKET 

CASE   #WRITS  CALL 


THEN 


POP    R2,  ORIS 
CALL   WRITE 

CASE   *WRITELN  CALL   THEN 


POP    R2,  ORIS 
CALL   WRITELN 

CASE   *CRLF  CALL 


THEN 


0100  7601 
0102  0100' 


POP    P.2,  0R15 
CALL   CP.LF 

ELSE  !  INVALID  KERNEL  INVOCATION! 

!  RETURN  TO  MONITOR  ! 

!  NOTE:  THIS  RETURN  TO  MONITOR  IS 
FOR  STUB  USE  ONLY.   AN  INVALID 
KERNEL  INVOCATION  WOULD  NORMALLY 
RETURN  TO  USER.  ! 

LDA    Rl,  $ 
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0104  2100       LD    R0,  #INVALID  KERNEL  ENTRY 

0106  0BAD 

0108  5F00        CAIL   MONITOR 

010A  A902 

FI 

!  SAVE  REGISTERS  ON  KERNEL  STACK  ! 

!  SAVE  Rl  ! 
010C  93F1     PUSH   GR15,  Rl 

!  GET  ADDRESS  OF  REGISTER  BLOCK  ! 
010E  34F1     LDA    Rl,  R15(#4) 
0110  0004 

!  SAVE  REGISTERS  IN  REGISTER  BLOCK 
ON  KERNEL  STACK.  ! 
0112  1C19     LDM    (?R1,  Rl,  #16 
0114  010F 

!  RESTORE  Rl  JUT  MAINTAIN  ADDRESS 
OF  REGISTER  ULOCK  ! 
0116  2DF1     EX     Rl,  PR15 

!  SAVE  Rl  ON  STACK  ! 
0118  33F1     ID     R15(#4),  Rl 
011A  0004 

!  RESTORE  REGISTER  BLOCK  ADDRESS  ! 
011C  97F1     POP    Rl,  fiR It) 

!  SAVE  VALID  EXIT  SP  VALUE  ! 
011E  33F1     LD     R15(#30),  Rl 
0120  001E 

!  EXIT  KERNEL  BY  MEANS  OF  HARDWARE 
PREEMPT  HANDLER  ! 
0122  5E08     JP     KERNEL  EXIT 
0124  0000* 

0126        END   GATE  KEEPER_MAIN 
END   KERNEL  GATE  KEEPER 


172 


Z8000ASM 

LOC     OB. 


2.02 

'  CODE 


STMT  SOURCE  STATEMENT 


0000 


TJSER_GATE  MODULE 

$IISTON      $TTY 

CONSTANT 

ADVANCE  CALL 
AWAIT  CALL 

C*EATE_SEG_CALL 

DELETE_SEG_CALL 

MAKE   KNOWN    CALL 

READ_CALL 

SM_StfAP_lN  CALL 

SM  SWAP_OUT_CALL 

TERMINATE_CALL 

TICKET_CALL 

WRITE_CALL 

WRITELN_CALL 

CRLF_CALL 

GLOBAL 

^SECTION  USER_GATE_PROC 


1 
2 

b 

6 

7 

8 

9 

10 

11 

12 

13 


ADVANCE 


PROCEDURE 


0000  7F01 
0002  9E08 
0004 

0004- 


*  PARAMETERS:  * 
v      Rl:SEGMENT   #  * 

*  R2:INSTANCE    (ENTRY*)5* 

-   RETURNS:  * 

*  R0:SUCCESS    CODE  * 

ENTRV 

SC  #ADVANCE_CALL 

RET 
END   ADVANCE 


AWAIT 


PROCEDURE 


*  PARAMETERS:  * 

*  R1:SEGMENT   #  * 

*  R2: INSTANCE  * 
-      RR4::SPECIFIED   VALUE    - 

*  RETURNS:  * 

*  P0: SUCCESS    CODE  * 

ENTRY 
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0004  7F02     SC     #AWAIT_CALL 
000b  9E08     RET 
0008        END   AWAIT 

0008        CREATE_SEG      PROCEDURE 

*  2,4  ?j*  *|*  *|*  3J5  3jC  J|l  J»»  *i*  i^i  ?i»  *i*  5|i  ?i*  *|J  5^  S|»  £|*  *»*  *|£  *|*  *%+  *i»  *»* 

*  PARAMETERS:  * 

*  Rl:MENTOR_SEG_NO  * 

-  R2:ENTRT_N0  * 

*  R3:SIZ£  * 

*  RR4: CLASS  * 

»j«  3i>  »i"  »i*  5|t  *,»  ?,»  i,i  3f»  Jti  J,*  i,I  2y*  *y*  *»t  i|"  3|S  #,:  ^,i  *,C  S^C  -,C  3JC  J,t 

*  RETURNS:  * 

*  R0:SUCCESS    CODE  * 

','  '|J  V  '.:  '«*  V  V  'I'  V  V  'l*  '.*  '^  *!'  »1*  '.;  V  '.*  'I1  '.*  ^  ^  '.*  'I'   T 

ENTRY 
0008  7F03     SC     #CREATE_SEC-_CALL 
000A  9E08     RET 
000C       END   CREATE_SEG 

000C        DELETERS  EG      PROCEDURE 

5:4   PARAMETERS  :  * 

*  Rl : MENTOR   SEG   NO  * 

-  R2:ENTRY_NO 

=?  *?  ^t  sp  *  W  sp  =*  a«c  sjc  Sit  a*  j*  a*  3*  sjc  jj«  s*  ap  3c  3*  3?  s? 

*  RETURNS:  * 

*  R0:SUCCESS    CODE  * 

ENTRY 
000C  7F04     SC     #DELETE_SEG_CALL 
000E  9E08     RET 
0010        END   DELETE_SEG 

0010        MAKE_KNOWN      PROCEDURE 

T  ^e  ^s  3?  sjc  sjt  >ic  ^c  ^c  ^c  ^t  jp  »;«  ^c  >jc  ^e  3?  5?  ^t  j;e  n«  J?  5?  n«  5F 

*  PARAMETERS :  * 

*  Rl:MENTOR_SEG_NO  * 

*  R2:ENTRY_N0  * 

-  R3:ACCESS    DESIRED        * 

- , »  *,*  *|»  *j»  ^!  Jj»  jf*  «f*  #j,c  3^«  Jj»  ; ,c  «|C  i^i  ^*  j,j  ;%x  ^  j4s  ^i  j,c  ;(;  s^c  ;,; 

*  RETURNS :  * 

*  R0:  SUCCESS    CODE  - 
"•   Rl: SEGMENT  # 

*  RH: ACCESS    ALLOWED        * 

3*  3?  3?  J£  33!  3*  3£  3?  a?  3?  3?  J?  3*3?:  3*  J?  3£  3^331  3?  331  3?  3?  331    | 

ENTRY 

0010  7F05     SC     #MAKE_£NOWN_CALL 

0012  9E08     RET 

0014        END   MAKE  KNOWN 
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0014  READ  PROCEDURE 

*  PARAMETERS: 

*  RlrSEGMENT  #        * 

*  ^2:  INSTANCE  * 

#i»  »(»  *i*  *i»  JJ»  »|»  *i%  *(»  J|S  »i%  *(S  J,»  »|»  J|«  *|*  »(•  ?|%  *|*  »(»  *)»  •%»  1»  *(•  #i» 

*  RETURNS:  * 

*  R0:SUCCESS    CODE  * 

*  RR4:EVENTCOUNT  * 

ENTRY 

0014  7F0b     SC     #READ_CAIL 
0016  9E0S     RET 

0015  END   READ 

001S  SMJSWAP_IN  PROCEDURE 

*  PARAMETERS:  * 

*  Rl:  SEGMENT  #        * 

*  RETURNS:  * 

*  R0:SUCCESS  CODE     * 

ENTRY 
0018  7F07     SC     #SM_SWAP_IN_CAIL 
001A  9E08     RET 
001C        END   SM_SWAP_IN 

001C        SM_SWAP_OUT     PROCEDURE 

*  PARAMETERS:  * 

*  RlrSEGMENT  #        * 

*  RETURNS:  * 

*  PB:  SUCCESS  CODE     - 

ENTRY 
001C  7F08     SC     #SM_SWAP_OUT_CALL 
001E  9E08     RET 
0020        END   SM_SWAP_OUT 

0020       TERMINATE       PROCEDURE 

*  PARAMETERS:  * 

*  Ri: SEGMENT  #         * 

*  RETURNS:  * 
-  P0r SUCCESS  CODE 

ENTRY 
0020  7F09     SC     ^TERMINATE  CALL 
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0022   9E4J8 


END      TERMINATE 


B024 


TICKET  PROCEDURE 

*  PARAMETERS:  - 

*  Pi:SEGMENT  #                     * 

<-,i   *|»  *|*  *i»   *»»  •»»   »,*   »|»  *»i  *|*   »i»  *,i  »,*  *|C  *|»   »|»   *,»   ifi   *,i   »,S  #{•    i,»  l|i   i,» 

*  RETURNS:  * 

*  R0:SUCCESS  CODE             * 

*  RR4: TICKET  7ALUE 

ENTRY 


0024 

7F0A 

SC           ^TICKET    CALL 

0026 

9E08 

RET 

0023 

END      TICKET 

002S 

dRITE  PROCEDURE 
ENTRY 

0028 

7F0B 

SC           #WRITE_CALL 

002A 

9E08 

RET 

002C 

END      WRITE 

002C 

VRITELN                        PROCEDURE 

ENTRY 

0  02C 

7F0C 

SC           #WRITELN_CALL 

002E 

9E08 

RET 

0050 

END      tfRITELN 

0030 

CRLF  PROCEDURE 
ENTRY 

0030 

7F0D 

SC           *CRLF_CALL 

0032 

9E08 

RET 

0034 

END      CRLF 
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APPENDIX  E  -  BOOTSTRAP  LOADER  LISTINGS 


Z8000ASM   2.02 
LOC     OBJ  CODE 


STMT  SOURCE  STATEMENT 
BOOTSTRAP  LOADER    MODULE 


TTPE 


SLISTON  STTY 

CONSTANT 

J   jjs^ajc^JiejFJjesje  SYSTEM  '. 

PARAMETERS  ******** 

NR  CPU          : 

= 

2 

NR  VP 

:  = 

NR  CPU*4 

NP.  AVAIL  VP      : 

-  = 

NR  C?U*2 

MAX  DBR  NR       i 

\  — 

10 

STACK.  SEG        : 

:  = 

1 

STACK  SEG  SIZE   : 

;  = 

%100 

STACK_3L0C"K     : 

'  = 

STACK_SEG_SIZE/25b 

!  *  *  OFFSETS  ] 

:n 

STACK  SEG  *  *  ! 

STAC!  BASE      : 

=s 

STACK  SEG  SIZJL-310 

STATUS  REG  BLOCK: 

:  = 

STACK  SEG  SIZE-%10 

INTERRUPT  FRAME  • 

;  = 

STACK  BASE-4 

INTERRUPT  REG    : 

'  = 

INTERRUPT  FRAME-34 

N  S  P 

:  = 

INTERRUPT  REG-2 

F_C_W 

j  = 

STACK  SEG  SIZE-£E 

i  w?wv  SYSTEM  CONSTANTS  ******  \ 

ON              : 

;  = 

%FFFF 

OFF 

:  = 

0 

READY 

:  = 

1 

NIL 

>  = 

%FFFF 

INVALID         : 

;  = 

tiij  Jl-  EE 

KERNEL  FCW 

:  = 

sseee 

AVAILABLE 

;  = 

0 

ALLOCATED 

;  = 

%jj 

SC  OFFSET       : 

;  = 

12 

MESSAGE   ARRAY 
ADDRESS   WORD 

lib    BY 

MM  VP  ID  WORD 

VP  INDEX 
MSG  INDEX 

INTEGER 
INTEGER 
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MSG  TABLE  RECORD 


t 


J 


*!SG 
SENDER 
NEXT_MSG 
FILLER 


MESSAGE 
7P  INDEX 
MSG  INDEX 
ARRAY  [6,  WORD] 


?P  TA3LE  RECORD 


[ 


DBR 
PR  I 
STATE 

IDLE  FLAG 

PREEMPT 


ADDRESS 


WORD 
WORD 
WORD 
WORD 


J 


PHTS 
NEXT_ 
MSG_LIST 
EXT_ID 
FILLER  1 


PROCESSOR   WORD 
READY  VP  VP  INDEX 


MSG_ INDEX 

WORD 

ARRAY  [7,  WOHDJ 


EXTERNAL 

GET_DBR_ADDR 
CREATE_STACK 
L  IS T_ INSERT 
ALLOCATE_MMU 
UPDATE  MMU  IMAGE 


PROCEDURE 
PROCEDURE 
PROCEDURE 
PROCEDURE 
PROCEDURE 


MM_ALLOCATE 

MM_ENTRY 

IDLE_ENTRY 

PREEMPT_"PET 
BOOTSTRAP_ENTRY 
GAT£_KEEPER 
NEXT    BLOCK 


PROCEDURE 
LABEL 
LABEL 
LABEL 
LABEL 
ENTRY  LABEL 
WORD 


MM_CPU_TBL  ARRAY  [NR_CPU  MM_VP_IDJ 


VPT 


RECORD 


LOCK 

RUNNING_LIST 

READY_LIST 

FREE_LIST 

VIRT_INT_VEC 

FILLER_2 

VP 

MSG  0 


WORD 

ARRAY [NR  CPU  WORDJ 
ARRAY  [NR~CPU  MORE] 
MSG_IND4X 
ARRA* [1,  ADDRESSJ 
WORD 
ARRAY  [NR_VPt  VP  TABLEJ 

ARRA*  [NR  VP,~MSG  TABLEJ 
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EXT_VP_LIST  ARRAY [NR_AVAIL    VP    WORDJ 

NEXT_AVAIL_MMU      ARRAY  lMAX_DBR3NR      BYTEJ 

PRDS  RECORD 

[FHJS_CPU  ID  WORD 
LOG_CPU_ID   INTEGER 
VP_NR        WORD 
IDIE_VP      VP_INDEX] 


INTERNAL 

^SECTION  LOADER_DATA 

!  NOTE:  THESE  DECLARATIONS  tfILL  NOT  WORK 
IN  A  TRUE  MULTIPROCESSOR  ENVIRONMENT  AS 
THET  ARE  SUBJECT  TO  A  "CALL."   THEY  MUST 
BE  DECLARED  AS  A  SHARED  GLOBAL  DATABASE 
WITH  "RACE"  PROTECTION  (E.G.,  LOCK).  ! 

0000      NEXT_A?AIL_VP    INTEGER 
0002      NEXT  EXT  VP      INTEGER 
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SSECTION   LOADER  INT 
INTERNA! 

0000  BOOTSTRAP  PPOC 

*  CREATES  KERNEL  PROCESSES 

*  INITIALIZES  KERNEL  DATAEA 

*  INCLUDES  INITIALIZATION  0 

*  VIRTUAL  PROCESSOR  TABLE, 

*  EXTERNAL  7P  LIST,  AND  MMU 

*  IMAGES.   ALLOCATES  MPU  IM 

*  AND  CREATES  KERNEL  DOMAIN 

*  STACK  FOR  KERNEL  PROCESSE 


EDURE 

AND  * 
SES.* 

f        5? 


AGE  * 
S  .   * 


0000  4D05 
0002  0000* 
0004  FFFF 


0006 

4D05 

LD 

0008 

0002* 

000A 

0002 

j 

000C 

4D05 

LD 

000E 

0004* 

0010 

0002 

0012 

4D08 

CLR 

0014 

0000* 

0016 

4D08 

CLR 

0018 

0000' 

001A 

4D08 

CLR 

001C 

0002' 

001E  7D15 


ENTRY 

!  INITIALIZE  PRDS  AND  MMU  POINTER  ! 

!  NOTE:  THE  FOLLOWING  CONSTANTS  ARE 
ONLY  TO  BE  INITIALIZED  ONCE.   THIS 
WILL  OCCUR  DURING  SYSTEM  INITIALIZATION! 

LD        PRDS. PHY S  CPU  ID,  #^FFFF 


NOTE:  LOGICAL  CPU  NUMBERS  ARE  ASSIGNED 
IN  INCREMENTS  OF  2  TO  FACILITATE  INDEXING 
(OFFSETS)  INTO  LISTS  SUBSCRIPTED  Bv 
LOGICAL  CPU  NUMBER.  ! 

PRDS. LOG  CPU  ID,  #2 


!    SPECIFY    NUMBER   OF    VIRTUAL   PROCESSORS 
ASSOCIATED    WITH    PHYSICAL    CPU.     ! 
PRDS.VP    NR,    #2 


NEXT_BLOCK 
NEXT_AVAIL_VP 
NEXT    EXT    VP 


!    ESTABLISH   GATE   KEEPER    AS    SYSTEM    CALL 

TRAP    HANDLER    ! 
!    GET   BASE   OF    PROGRAM   STATUS    AREA    ! 
LDCTL  Rl,    PSAP 


0020    0101 
0022    000C 

0024    0D15 
0026    5000 


!    ADD    SYSTEM    CALL    OFFSET    TO    PSA    BASE    ADDR    ! 
ADD  Rl,    #SC_OFFSET 

!    STORE    KERNEL    FCW    IN    PSA    ! 
LD  GR1,    #KERN£L_FCW 
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0028  A911 
002A  0D15 
002C  0000* 
002E  8D18 


!  STORE  ADDRESS  OF  SATE  KEEPER  IN  PROGRAM 

STATUS  AREA  AS  SYSTEM  TRAP  HANDIER  ! 
INC        Rl,  #2 
LD        (?R1,  #GATS  KEEPER  ENTRY 


CI? 


P.l   !  NEXT  AVAIL  MMU  INDEX  ! 


!  INITIALIZE  ALL  MMU  IMAGES  AS  AVAILABLE  ! 
SET_MMU_MAP: 

DO 


0030 

4C15 

LDiJ 

NEXT_AVAIL_MMU(R1),  #AVAILA£LE 

0032 

0000* 

0034 

0000 

0036 

A910 

INC 

Rl,  Ul 

!  CHECK  FOP  END  OF  TABLE  ! 

0038 

0B01 

CP 

Rl,  *MAX_DBR_NR 

003A 

000A 

003C 

5E0E 

IF  EO  THEN  EXIT  FROM   ET_MMU_MAP 

003E 

0044' 

0040 

5E08 

0042 

0046' 

0044 

E8F5 

OD 

!  CREATE 

MEMORX  MANAGER  PROCESS  ! 

0046 

2103 

LD 

R3,  #STACK_BLOCK 

0048 

0001 

!  ALLOCATE  AND  I N 1 1 

DOMAIN 

STACK  SEGMENT  ! 

004A 

5E00 

CALL 

MM_ALLOCATE   !R3:  #  OF  BLOCKS 

004C 

0000* 

RETURNS 

R2:  START  ACPR ! 

004E 

A121 

LD 

Rl,  R2 

0050 

2103 

LD 

R3,  #KERNEL_FCW 

0052 

5000 

0054 

7604 

LDA 

R4,  MM_SNTRY 

0056 

0000* 

0058 

6105 

LD 

R5,  2FFFF   !NSP! 

005A 

FFFF 

005C 

7606 

LDA 

R6,  PREEMPT_RET 

005E 

0000* 

0060 

93F1 

PUSH 

(?Rl5t  Rl  !SAVE  STACK  ADDR! 

0062 

030F 

SUB 

R15,  #8 

0064 

0008 

0066 

1CF9 

LDM 

0R15,  R3,  #4 

0068 

0303 

006A 

A1F0 

LD 

R0,  R15 

!  NOTE:  ARGLIST  FOR  CREATJS  STACK  INCLUDES 
KERNEL  FCW,  INITIAL  IC ,  NSP,  AND  INITIAL 
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006C  5F00 
006E  0000* 


0070  010F 
0072  0009 

0074  5F00 
0076  0000* 

0075  2101 
007A  0001 
007C  97F2 
007E  2103 
0080  0000 


0082  2104 
0084  0000 

0086  93F0 


RETURN  POINT.  ! 
CALL       CREATE  STACK 


!  (R0:  ARGUMENT  PTR 


ADD 


Hi:  TCP  OF  STACK 
R2-R14:  INITIAL 
^  E  G  STATES  ! 
Rib,  #8   !OVERLAY  ARGUMENTS! 


!  ALLOCATE  MMU  IMAGE  ! 
CALL       ALLOCATE  MMU 


LD 

POP 
LD 


HI,    frSTACK    SEG 


!RETURNS: 

(R0:  DBR  #)  ! 
!  SEGMENT  NO 


R2,  GR15   !GET  STACK  ADER! 
R3,  #0     !  "VRITE  ATTRIBUTE  ! 


i  SPECIFY  NUMBER  OF  BLOCKS.  COUNT  STARTS 

FROM  ZERO.  (I.E. ,1  BLOCK=0,  2=1,  ETC.)! 
LD        R4.  #STACK_£LOCK-l 

!  SAVE  DBR  #  ! 
PUSH       GR15,  R0 


008e  5F00 
008A  0000* 


008C  97F0 


008S  5F00 
0090  0000* 


!  CREATE  MMU  ENTRY  FOR  MM  STACK  SEGMENT  ! 
CALL      UPDATE  MMU  IMAGE   !(R0:  DBR  * 


Rl 
R2 

R3 
R4 


!  RESTORE  DBR  #  ! 
POP         R0,  GR15 


SEGMENT  # 
SEG  ADDRESS 
SEG  ATTRIBUTES 
SEG  LIMITS)   ! 


0092 

2102 

LD 

0094 

0002 

0096 

2105 

LD 

0098 

0000 

009  A 

2106 

LD 

009C 

0000 

009E 

5F00 

i 

CA 

00A0 

01CA' 

!  GET  ADDRESS  OF  MMU  IMAGE  ! 

CALL       GET_D£R_ADDR   !  (R0:  DER  rt) 

RETURNS: 

(Hi:  DBR  ADDRESS)  ! 
!  PREPARE  VP  TABLE  ENTRIES  FOR  MM  ! 
R2,  #2      !  PRIORITY  ! 


R5,  #OFF     !  PREEMPT  ! 

R6,  #OFF   !  KERNEL  PROCESS  ! 


!  UPDATE  VPT  ! 

UPDATE_7P_TABLE   !(R1:  DER 

R2:  PRIORITY 
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R.5:  PREEMPT  FIAG 
R6:  EXT_7P  FLAG) 
RETURNS : 
R9:  VP_ID  ! 

!  INITIALIZE  MM_CPU_TEL  IN  DISTRIBUTED  MEMORY 
MANAGER  WITH  VP  ID  OF  MM  PROCESS  ! 

!  GET  LOGICAL  CPU  #  ! 


00A2 

610A 

LD  R10, 

PRDS.LOG_CPU_ID 

00A4 

0002* 

00A6 

6FA9 

LD 

MM_CPU_T£L(R10),  R9 

00A8 

0000V 

!  CREATE 

IDLE  PROCESS  ! 

00AA 

2103 

LD 

R3,  #STACK_BIOCK 

00AC 

0001 

00AE 

5F00 

CALL 

MM_ALLOCATE  !R3:  #    OF  BLOCKS 

00B0 

0000* 

RETURNS 

R2:  START  ADDR! 

00B2 

A121 

LD 

Rl,  R2 

00B4 

2103 

LD 

R3,  #KERNSL_FCW 

00E6 

5000 

00B8 

7604 

LDA 

R4,  IDLE_ENTRY 

00BA 

0000* 

00BC 

2105 

LD 

R5,  #£FFFF  !NSP! 

00BE 

FFFF 

00C0 

7606 

LDA 

R6,  PRESMPT_RET 

00C2 

0000* 

00C4 

93F1 

PUSH 

GR15,  Rl  !SAVE  STACK  ADDR! 

00C6 

030F 

SUB 

R15,  #8 

00C8 

0008 

00CA 

1CF9 

LDM 

0R15,  R3,  #4 

00CC 

0303 

00CE 

A1F0 

LD 

R0,  R15 

!  INITIALIZE  IDLE  STACK  VALUES  ! 

00D0 

5F00 

CALL 

CREATE_STACK   !  (R0:  ARGUMENT 

00D2 

0000* 

00D4  010F 
00D6  0008 


ADD 


Rl  :  TOP  01  STACK 
R2-R14:  INITIAL 
REG.  STATES  ' 
R15,  #8  ! OVERLAY  ARGUMENTS! 


00D8  5F00 
00DA  0000* 


!  ALLOCATE  MMU  IMAGE  FOR  IDLE  PROCESS  ! 
CALL       ALLOCATE  MMU   !  RETURNS  R0:DBR  #  ! 


00DC  2101 
00DE  0001 
00E0  97F2 


!  PREPARE  IDLE  PROCESS  MMU  ENTRIES  ! 
LD        Rl,  #STACK  SEG   !  SEG  #  ! 


POP 


R2,  CR15   !GET  STACK  ADDR! 
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00E2  2103 
00E4  0000 
00E6  2104 

00E8  0000 

00EA  93F0 


00EC  5F00 
00EE  0000* 


00F0  97F0 


00F2  5F00 
00F4  0000* 


00F6  2102 
00F8  0000 
00FA  2105 
00FC  0000 
00FE  2106 
0100  0000 


LD 
LD 


R3,    #0  !     WRITE    ATTRIBUTE    ! 

R4,    #STACK    BLOCK-1       !    BLOCK    LIMITS    ! 


!    SAVE   DBR    n    ! 
PUSH  (3R15,    Re 

!  CREATE  MMU  IMAGE  ENTR7"  ! 
CALL       UPDATE  MMU  IMAGE 


!  (31:  SEGMENT  # 

R2:  SEG  ADDRESS 
A3:  SEG  ATTRIBUTES 
R4:  SEG  LIMITS  )  ! 


!  RESTORE  DBR  #  ! 
POP       R0,  CR15 

!  GET  MMU  ADDRESS  ! 
CALL       GET  DBR  ADDR 


!  (P.0:  £BR  #) 


RETURNS 

(Rl:  DBR  ADDRESS)  ! 
!  PREPARE  VPT  ENTRIES  FOR  IDLE  PROCESS  ! 
LD        R2,  #0  !  PRIORITY  ! 


LD 
LD 


R5,  #OFF 
R6,  #OFF 


!  PREEMPT  ! 

!  KERNEL  PROC  ! 


!  CREATE  VPT  ENTRIES  ! 


0102 

5F00 

CALL      U?DATE_VP_TABLE   !(Rl:  DBR 

0104 

01CA' 

R2:  PRIORITY 
R4:  IDLE  FLAG 
R5:  PREEMPT 
R6:  EXT  VP  FLAG^ 
RETURNS : 
R9:  VP  ID  ! 
!  ENTER  VP  ID  OF  IDLE  PROCESS  IN  FRDS  ! 

0106 

6F09 

LD        PRDS.IDLE_VP,  P9 

0108 

0006* 

!  INITIALIZE  IDLE  VP 'S  ! 

010A 

2102 

LD        R2,  *1           !  PRIORITY  ! 

010C 

0001 

010E 

2105 

LD         R5,  #ON          !  PREEMPT  ! 

0110 

FFFF 

0112 

2106 

LD         R6,  #ON          ! NON-KERN  EL  PROC! 

0114 

FFFF 

0116 

6100 

LD        R0,  PRDS.VP_NR 

0118 

0004* 

!  INITIALIZE  VP  VALUES  ! 
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011A  5F00 
011C  01CA' 


CO 

CALL 


UPDATE  VP  TA3LS   !(R1:  DBE 


R2:  PRIORITY 

R4:  IELE_FLAG 

R5:  PREEMPT 

R6:  EXT_VP  FLAG) 

RETURNS: 

R9:  VP  ID  ! 


011E 

AB00 

EEC 

0120 

0B00 

CP 

0122 

0000 

0124 

5E0E 

IF 

0126 

012C' 

0128 

5E08 

012A 

012E' 

FI 

012C 

E8F6 

OD 

!  IN 

!  GE 

012E 

6102 

LD 

0130 

0002* 

0132 

4D05 

LD 

0134 

0000* 

0136 

0000 

0138 

4D25 

LD 

013A 

0002* 

013C 

FFFF 

013E 

4D25 

LD 

0140 

0006* 

0142 

FFFF 

0144 

4D08 

CLR 

0146 

000A* 

R0,  #1 
R0,  #0 


IF  EC  !ALL  VP'S  INITIALIZED!  THEN 


EXIT 


!  INITILIZE  VPT  HEADER  ! 
!  GET  LOGICAL  CPU  NUMBER  ! 

R2,  P?DS.LOG_CPU_ID 

VPT. LOCK,  *OFF 


VPT. RUNNING    LIST(R2),    #NIL 


VPT. READY    LIST(R2),    ffNIL 


VPT. FREE  LIST   !HEAD  CF  MSG  LIST! 


!THREAD  VP 'S  BY  PRIORITY  AND  SET  STATES  TO  READY  ! 
0148  6D28     CLR        R2   JSTART  WITH  VP  #1! 


014A  610D 
014C  0002* 
014E  7bD3 
0150  0006* 

0152  7604 
0154  001C* 
0156  7605 
0158  0012* 
015A  7606 
015C  0014* 
015E  2107 


THREAD: 
DO 
LD 

LDA 

LDA 

LDA 


LDA 


LD 


R13,    PRDS.LOG_CPU_ID 
R3,VPT.READT_LIST(R13) 
R4, VPT.VP.NE7T_READY_VP 
R5.VPT.VP.PRI 

R6, VPT. VP. STATE 
R7,#READY 
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0160  0001 

0162  93F2 
0164  5F00 
0166  0000* 


!  SAVE  OBJ  ID  ! 

PUSH     GR15.  R2 

CALL    LIST  INSERT  !R2:  OBJ  ID 


R3 

R4 
R5 

?.6 
R7 


LIST_HEAD  PTR  ADDR 
NEXT_OBJ  PTR 
PRIORITT_PTR 
STATE_PTP. 
STATE    ! 


0166 

97F2 

ei6A 

0102 

016C 

0020 

016S 

0E02 

0170 

0100 

0172 

5E0E 

0174 

017A' 

0176 

5E08 

0173 

017C' 

017A 

E8E7 

!  RESTORE  OBJ  ID  ! 

POP     R2,  GR15 

ADD      R2,  #SIZEOF  VP_TABL£ 

CP       ?2,  #(NR_VP  *  (SIZEOF  V?_TAELE)) 

IF  EO  THEN  EXIT  FROM  THREAD  FI 


017C  8D1S 


MSG 


OD 


!  INITIALIZE  VP  MESSAGE  LIST  ! 

!  NOTE:  ONL^  THE  THREAD  FOR  THE  MESSAGE 
LIST  NEED  BE  CREATED  AS  ALL  MESSAGES 
ARE  INITIALLY  AVAILABLE  FOR  USE.  THE 
INITIAL  MESSAGE  VALUES  WERE  CREATED 
FOR  CLARITY  ONLY  TO  SHOW  THAT  THE 
MESSAGES  HAVE  NO  USABLE  INITIAL  VALUE! 

CLR        Rl 

LST_INIT: 

!  NOTE:  Rl  REPRESENTS  CURRENT  ENTRY  IN 
MSG_LIST,  R2  REPRESENTS  CURRENT  POSITION 
IN  MSG_LIST  ENTRY,  AND  R3  REPRESENTS 
NEXT  ENTR^  IN  MSG  LIST.  ! 
DO 


017E 

A112 

LD 

R2t  Rl 

0180 

A123 

LD 

R3,  R2 

0182 

0103 

ADD 

R3,  #SIZSOF  MESSAGE 

0184 

0010 

FILL  MSG: 
DO 

0186 

4D25 

LD 

VPT.MSG_C.MSG(R2) ,  #INVALID 

0188 

0110* 

018A 

EEEE 

018C 

A921 

INC 

R2,  #2 

018E 

8B32 

CP 

R2,  R3 

0190 

5E0E 

IF  EO  T 

HEN  EXIT  FROM  FILL  MSG  FI 

0192 

0198' 

0194 

5E08 
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0196 

019A 

0198 

ESF6 

OD 

019A 

4D15 

LD 

019C 

0120* 

019S 

FFFF 

01A0 

A112 

LD 

01A2 

0101 

ADD 

01A4 

0020 

01A6 

0P01 

CP 

01  A3 

0100 

IF  EC 

01AA 

5E0E 

THEN 

01AC 

01BC' 

01AE 

4D25 

LD 

01B0 

0122' 

01B2 

FFFF 

0134 

5E08 

EXIT 

01B6 

01C2' 

01*8 

5E08 

ELSE 

01BA 

01C0' 

01BC 

6F21 

LD 

01BE 

0122* 

01C0  E8DE 


01C2 

01C4 


610D 
0002* 


01C6  5E08 
01C8  0000s 
01CA 


VPT.MSG   Q.SENDER(Rl),    *NIL 


R2,    Rl 

Rl,    tfSIZEOF    MSG_TABLE 

Rl,    #SIZEOF    MSG_TA£LE*NR_VP 


VPT.MSG_Q.NEXT_MSG(R2),    #NIL 
FROM    MSG_LST_IN1T 

VPT.MSG_Q.NEXT_MSG(R2),    Rl 


OD 


!  GST  LOGICAL  CPU  #  FOR  USE 

BY  ITC  GETWORK.  ! 
LD  R13,  PRDS .LOG_CPU_ID 

!  BOOTSTRAP  COMPLETE  ! 

!  START  SYSTEM  EXECUTION  AT  PREEMPT  ENTRV  ! 

!  POINT  IN  ITC  GETVORK.  PROCEDURE  ! 

JP         HOOTSTRAP_ENTRY 

END  BOOTSTRAP 
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01CA 


UPDATE   VP    TABLE  PROCEDURE 

*  INITIALIZES    VPT    ENTRIES  * 

2y£  *,**,»  ijC  i,i  i,i  j^i  5|C  *^  ;,c  ;,i  i,s  j,«  £,£  «^c  »,»  J^  i,i  «,£  .*,»  *,i  J#s  2^*  »,*  J,;  i,i  Tfi  5^C  J,C  JJ»  *,*  Z£ 

*  REGISTER   USE:  * 

*  PARAMETERS:  * 

*  Rl:  DBR  ADDRESS  * 
R2:  PRIORITY  * 
R5:  PREEMPT  FLAG  * 
Rb:    EXTERNAL   VP    FLAG 

RETURNS: 
R9:    ASSIGNED    V?    ID 

LOCAL    VARIABLES:  * 

R7:    LOGICAL    CPU    *  » 

R8:    EXT_VP_LIST    OFFSET  * 

R9:    VPT   OFFSET  * 


5? 
5? 


01CA 

6ie9 

LD 

01CC 

0000' 

01CE 

6F91 

LD 

01D0 

0010* 

01D2 

6F92 

LD 

01D4 

0012s? 

01D6 

6F96 

LD 

01D8 

0016* 

01DA 

6F95 

LD 

01DC 

0018* 

01DE 

6107 

LD 

01E0 

0002* 

01E2 

6F97 

LD 

01E4 

001A* 

01E6 

4D95 

LD 

01E8 

001C* 

01EA 

FFFF 

01EC 

4D95 

LD 

01EE 

001E* 

01F0 

FFFF 

01F2 

0B06 

; 

CP 

01F4 

FFFF 

T' 

01F6 

5E0E 

1. 

t: 

01F8 

0210' 

01FA 

6108 

01FC 

0002' 

01FE 

6F89 

ENTRY 

!    GET    OFFSET    IN    VPT    FOR    NEXT    ENTRY    ! 
R9,    NEXT_AVAIL_VP 

V?T.VP.DBR(R9) ,    Rl 

VPT.VP.PRKR9)  ,    R2 

VPT.V?.IDLE_FLAG(R9) .    Rb 

VPT. VP. PREEMPT (R9 )  ,    R5 

R7,    PRDS .LOG_CPU_IE 

VPT.VP.PKYb_PROCESSOR(Ry^,    R7 

VPT.VP.NEXT_PEADT_VP(R9) ,    *NIL 

VPT.VP.MSG    LIST(R9),    #N II 


!    CHECK    EXTERNAL   VP    FLAG    ! 
R6,    #ON 

IF    EO    ! EXTERNAL   VP! 

TEEN       !    VP    IS    TC   VISIBLE    ! 


LD 


R8,    NEXT    EXT    VP 


!     INSERT    ENTRY    IN    EXTERNAL    VP    LIST    ! 
LD  EXT_VP_LIST(R8),    R9 
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0200  0000* 

0202  6F98       LD      VPT.VP.EXT  ID(R9) ,  Rb 

0204  0020* 

0205  Ay81        INC      R8f  #2 

020e  6Fee  ld  nsxt_extjtp.  Re 

020A  0002' 

020C  5E08       ELSE   !V?  BOUND  TO  KERNEL  PROCESS! 

020E  0216' 

0210  4D05        LD       VPT.VP.EXT_ID,  #NIL 

0212  0020* 

0214  FFFF 

FI 
0216  A19A      LD        Rl0,  R9 
0218  010A      ADD        R10,  #SIZ£OF  VP_TA£LE 
021A  0020 

021C  6F0A      LD         NEXT  AVAIL_VPf  R10 
021E  0000' 
0220  9E08      RET 
0222        END  UPDATE  VP  TABLE 
END  BOOTSTRAP  LOADER 


189 


APPENDIX  I   -  LIBRARY  JUNCTION  LISTINGS 


Z6000ASM 
LOC     OB 


2.02 

■  corE 


STMT    SOURCE    STATEMENT 


LIERAR^_FrjNCTION       MODULE 
$LISTON    $TTY 


CONSTANT 

KERNEL_FCW 

STACK_SEG_SIZE 

STACK~BASE 

STATUS_REG_BLOCK 

INTERRUPT_FRAME 

INTERRUPT_REG 

N_S  P 

NIL~ 


%5000 

^100 

STACK  SEG  SI ZE-%10 

STACK  SSG_SIZE-£10 
STACK_PASE-4 
INTERRUPT  FRAME-34 

INTERRUPT_REG-2 
%FFFF 
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$SECTION    LIB_PPOC 
GLOBAL 

0000                       LIST_1NSERT  PROCEDURE 

*  INSERTS    OBJECTS    INTO    A    LIST 

*  BY    ORDER    OF    PRIORITY    AND    SETS  * 

*  ITS    STATS  * 

*  REGISTER   USE:  * 

*  PARAMETERS:  * 

*  R2:    OEJECT    ID  * 

*  R3:    HEAD_OF_LIST    PTR   ADDR  * 

*  R4:    NEXT   OBJ_PT?~ADDR  -  * 

*  R5:    PRIORITf_PTR   ADDR  * 

*  R6:    STATE_PTR   ADDR  * 

*  R7:    OBJECT   STATE  * 

*  LOCAL   VARIABLES:  * 

*  R£:    HEAD  OF  LIST   PTR  * 

*  R9:    NEXT_OBJ_PTR  * 

*  R10:    CURRENT_OBJ   PRIORITY  * 

*  R11?     WTTTT     f)HT     PPTDPTTY  * 


^^s^sS^sp^r.iJ^^^^^^t^s^^^^r^Jis^^^^V^'^^^^^^V  ! 


0000  2138 
0002  0E08 
0004  FFFF 
0006  5E0E 
0008    0018' 

000A  2F32 
000C  7449 
000E  0200 
0010  0D95 
0012  FFFF 
0014  5E08 
0016    005A' 


£018 

001A 
001C 
001E 
0020 
0022 
0024 
0026 
0028 
002A 
002C 


715A 

0200 

715B 

0800 

8BBA 

5E02 

0£30' 

2F32 

7348 

0200 

5E08 


ENTRY 

!    GET  FIRST    OBJECT    IN    LIST    ! 

LD  R8,    PR3 

CP  R8,    #NIL 

IF    EO  !LIST    IS    EMPTY!    THEN 

!    PLACE    OBJ    AT    HEAD    OF    LIST    ! 
LD  @R3,    R2 

LDA  R9,    R4(R2) 


LD 
ELSE 


PR9,    *NII 


!    COMPARE    OBJ    PHI    WITH    LIST    HEAD    PRI     ! 
LD  R10,    R5(R2)     !OBJ    PRI! 


LD 


Rll,    R5(R8)     !HEAD    PRI! 


CP  R10,    Rll 

IF   GT    !0BJ    PRI>HEAD    PRI!    THEN 


LD 
LD 


GR3,    R2       !PUT    AT    FRONT! 
R4 ( R2  )  ,    R8 


ELSE    !    INSERT    IN    BODY    OF    LIST    ! 
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00  2E  005A' 

SEARCH  LIST: 
DO" 
0030  0B08       CP  R8,  *NIL 

0032  FFFF 

^034  5E0E        II  EO  !END  OF  LIST!  THEN 
0036  003C  ' 

0038  5E08        EXIT  FROM  SEARCH  LIST 
0e3A  0052' 

FI 
003C  715B        LD  Rll,  35  (RS)  !GET  NEXT  FRI  ! 

003E  0800 

0040  8BBA       CP  R10,  Rll 

0042  5E02        IF  GT  !  CURRENT  PRnNEXT  PRI!  THEN 
0044  004A' 

0046  5E08         EXIT  FROM  SEARCH_LIST 
0048  0052' 

FI 

!  GET  NEXT  OBJ  ! 
004A  A189        LD  R9 ,  RS 

004C  7148        LD  R8,  R4(R9) 

004E  0900 

0050  EfcEF       OD    !  END  SEARCH_LIST  ! 

!  INSERT  IN  LIST  ! 
0052  7348       LD  R4(R2) t  RS 

0054  0200 

0056  7342       LD  R4(R9)  ,  P.2 

0058  0900 


FI 
FI 

!  SET  OBJECT'S  STATE  ! 
005A  7367     LD  R6(R2)  ,  R7 

005C  0200 
005E  9E08     RET 
0060        END  LIST  INSERT 
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0060 


C"R£AT^_STACK 
!  * 


PROCEDURE 


*i*  *i*  *i*n»'i*5l*^ii*»?^'i(S3i;S^5i*i^^5JiS5iS  *i*  *^  ^  ^  v  ;,»  v  ^;  ;^  ^;  ^i  v  V  v 


INITIALIZES    KERNEL    STACK 
SEGMENT   FOP.    PROCESSES 


* 
* 


i^m    #!* »|*  i,»  *|«  »,C  »|£  *|i  i^  ^,C  *,*  *,*  J,%  3£  i^C  J^5  *^I  *fC  5,1  Jj»  *|%  ijC  *»S  »,i  3|C  i»%  J|C  2tZ   ',*  J|I  J,C  *,i 


REGISTER   QSE: 
PARAMETERS: 
R0:    ARGUMENT    POI 
(INCLUDES :ICW,IC 
RETURN    POINT.    S 
VARIABLES    BELOW 
Rl:    TOP   OF   STACK 
R2-R14:    INITIAL 
STATES.    (NOTE: 
SPECIFIC    INITIA 
VALUES    ARE    SET, 
(USER    ID)    FOR   U 
CESSES. ) 

LOCAL    VARIABLES 
(FROM    ARGUMENTS    S 

STACK.) 

R3:    FCW 

R4:    PROCESS    ENTR 

R5:    NSP 

R6:    PREEMPT    RETU 

T**l*  *^  *|*  •»"  *l*  ^P  *|*  ^^  *^  *^  *^  *^  ^^  T*  TP  *^  *|*  *^ 


NTER  * 

,NSP,    AND  * 

EE    LOCAL  * 

)  * 

REGISTER  * 
IN  DEMO,  NO* 
L  REGISTER  * 
EXCEPT  R13* 
SEP    PRO-        * 

>>[»    *i»    ^|%  J^-»    #J%    *|%  «|*    .*,»     *^    «|%    *)>    *|» 

TCRED    ON         * 

Y    POINT(IC)* 
RN    POINT         * 


0060 

93F0 

e062 

ArF0 

0064 

341F 

0066 

00CA 

0068 

1CF9 

006A 

010F 

006C 

A10F 

006E 

97F0 

0070 

A1FE 

0072 

A10F 

0074 

1CF1 

0076 

0303 

007S 

341F 

007A 

00EC 

007C 

1CF9 

007E 

0301 

0080 

341F 

0082 

00C8 

0084 

2FF5 

0086 

030F 

ENTRY 

PUSH 

EX 
LDA 

LDM 


ORIS,    R0    !SAVE    ARGUMENT    PTP  ! 
R0,    R15       !SAVE    SP! 
R15,    R1(#INTERRUPT_REG) 

ORIS,    Rl,    *16       ! INITIAL    REG.    VALUES! 


!    MOTE:    0NL7    REGISTERS    R2-R14    MAT    CONTAIN 
INITIALIZATION    VALUES    ! 


ID 

POP 

LD 

LD 

LDM 

LDA 

LDM 

LDA 

LD 
SUB 


R15,    R0       ! RESTORE    SP! 

R0,    GR15    !  RESTORE    ARGUMENT    PTR! 

R14,    Rib    !SAVE    CALLER    RETURN    POINT! 

R15,    R0      !G£T    ARGUMENT    PTP! 

R3,    GR15,    *4    !LOAD    ARGUMENTS! 

Rib,    R1(#INTERRUFT_FRAME) 

(?R15,    R3,    UZ    !INIT    I  RET    FRAME! 

R15,    Rl(*N_S_?) 

PR15,    R5       !SST    NSP! 
R15,    #2 
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0088  0002 

008A  2FF6  ID        0R15,  R6  ! PREEMPT  RET  POINT! 

008C  3418  IDA       R8f  Rl (#STACK  BASE  ) 

008E  00F0 

!  INITIALIZE  STATUS  REGISTER  RLOCK  ! 

0090  2100  ID                    R0,  #KERNEI_FC'v 
0092  5000 

0094  1C89  LDM        (?R8,  R15,  *2   !SAVE  SP  *  FCW ! 
0096  0F01 

0098  A1EF  LD        R15,  R14   IRES  TORE  RETURN  POINT! 

009 A  9E08  RET 

009C  END  CREATE_STACK 

END  LIERARY  FUNCTION 
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APPENDIX  G  -  INNER  TRAFFIC  CONTOLLER  LISTINGS 


ZS000ASM   2.e2 
IOC     OBJ  CODE 


STMT  SOURCE  STATEMENT 
INNER  TRAFFIC  CONTROL  MODULE 


$LISTON  $tty 

.  GETWORK: 

A.  NORMAL  ENTRY  DOSS  NOT  SAVE  REGISTERS. 

(  THIS  IS  A  FUNCTION  OF  THi  GATEK1EFER  ). 

B.  R14  IS  AN  INPUT  PARAMETER  TO  GETWORK  THAT 
SIMULATES  INFO  THAT  WILL  EVENTUALLY  JBE  ON 
THE  MMU  HARDWARE.   THIS  REGISTER  MUST  BE 
ESTABLISHED  AS  A  DBR  EY  ANY  PROCEDURE 
INVOKING  GETWCRK. 

C.  THE  PREEMPT  INTERRUPT  ENTRY  HANDLER  DOES 
NOT  USE  THE  GATEKEEPER  AND  MUST  PERFORM 
FUNCTIONS  NORMALLY  ACCOMPLISHED  BY  IT 
PRIOR  TO  NORMAL  ENTRY  AND  EXIT. 
(  SAVE/RESTORE:  REGS,  NSPJ  UNLOCK  VPT,  TEST  INT 


2.  GENERAL: 

A.  ALL  VIOLATIONS  OF  VIRTUAL  MACHINE  INSTRUCTIONS 
APE  CONSIDERED  ERROR  CONDITIONS  AND  WILL  RETURN 
SYSTEM  TO  THE  MONITOR  WITH  AN  ERROR  CODE  IN  R0 
AND  THE  PC  VALUE  IN  Rl . 

B.  ITC  PROCEDURES  CALLING  GETWORK  PASS  DPR 
(REGISTER  R14)  AND  LOGICAL  CPU  NUM££R 
(REGISTER  R13)  AS  INPUT  PARAMETERS. 
(INCLUDES:  SIGNAL,  WAIT,  SWAP_VDrP, 

PHYS  PREEMPT  HANDLER,  AND  IDLE).   ! 


CONSTANT 

I  vv******** 

U_L  :=  e 

M_L_EM  :=  1 

M  L  ER  :=  2 

R"0  :=  3 

M_L_0  :=  4 

SNA  :=  5 

V~I~E  :=  6 

M  U~  :=  7 


ERROR  CODES  **********  t 

UNAUTHORIZED  LOCK  ! 

MESSAGE  LIST  EMFTY  ! 

MESSAGE  LIST  ERRC73  ! 

READY  LIST  tMPTY  ! 

MESSAGE  LIST  OVERFLOW 
!  SWAP  NOT  ALLOWED  ! 
!  VP  INDEX  ERROR  ! 
!  MMU  UNAVAILABLE  ! 


NR_SDR 

NR_CPU 

NR_VP 

NR  AVAIL  VP 


SYSTEM  PARAMETERS  ********  f 
=  64    !LONG  WORLS! 
=  2 

=  NR_CPU*4 
=  NR~CPU*2 
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MAX_DPP_NR 
STACK_SEG 
PHDS  SEG 
STACK  SEG  SIZE 


=  10 
=  1 
=  0 

=  %100 


?PER  CPU! 


I  *****  OFFSETS  IN  STACK  SEG  *****  ! 


STACK  BASE 
STATUS  REG  BLOCK 
INTERRUPT  FRAME 

INTERRUPT_REG 

N_S_P 

F    C    W 


ON 

OFF 

RUNNING 

READY 

WAITING 

NIL 

INVALID 

MONITOR 

KERNEL_FCW 

AVAILABLE 

ALLOCATED 


STACK_SEG  SIZE-%10 
STACK_SEG~SIZE-*10 
STACK  BASE-4 
INTERRUPT  FRAME-34 

INTERRUPT  REG-2 
STACK  SEG~SIZE-2E 


=  %FFFF 

=  0 

=  0 

=  1 

=  2 

=  £FFFF 

=  %EEEE 

:=  £A900 

=  %5000 
=  0 
=  %FF 


!  HSUG  ENTRY  ! 


TYPE 

MESSAGE   ARRAY  [16 
ADDRESS   WORD 


EYTEJ 


VP_INDEX 
MSG    INDEX 


INTEGER 
INTEGER 


SEG  DESC  REG   RECORD 


[ 


PASE       ADDRESS 
ATTRIBUTES         P.YTE 
LIMITS  PYTE 


J 


MMU 


ARRAY  [NR    SDR    SEG    DESC    REGJ 


MSG_TAPLE   RECORD 

[    MSG  MESSAGE 

SENDER  VF_INDEX 

NEXT_MSG  MSG_INDEX 

FILLER  ARRAY     [6,    WORLJ 

J 
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VP  TABLE  RECORD 
~  [  D.bR    ADDRESS 

PP.  I  WORD 

STATS         WORD 

IDL£_FLAG      WORD 

PREEMPT        WORD 

PHIS  PROCESSOR   WORD 

NEXT    READY_V?    VP_INDEX 

MSG_LIST       MSG_INDEX 

EXT  ID         WORD 

FILLER  1       ARRAY  [7,  WORE] 


EXTERNAL 

LIST_INSERT        PROCEDURE 

GLOBAL 

BOOTSTRAP_ENTRY        LABEL 

$SECTION  1TC_DATA 

0000         VPT       RECORD 

[  LOCK  WORD 

RUNN1NG_LIST  ARRAY  [NR_CPU    WORDJ 

READY    LIST  ARRAY  [NR    CPU    WORDJ 

FREE_IIST  MSG_IND£X 

VIRT_INT_VEC  ARRAY  [1,    ADTRESSJ 

FILLER_2  WORD 

VP  ARRAY     [NR    VP ,    VP_TAELEJ 

MSG_0  ARRAY     [NR_VP.    MSG-   TAJbLfiJ 

J 
0210  EXT_VP_LIST      ARRAY [NR_AVAIL_VP      WORDJ 

$SECTION    MMU_DATA 

0000  MMU  IMAGE        RECORD 

"[ 

MMU  STRUCTURE       ARRAY  [MAX  DBR  NH   MMU  J 

] 

0A00          NEXT_AVAIL_MMU  ARRAY [MAX  DBR  NR   BYTE] 
0A0A         PPDS     RECORD 

LPHYS_CPU  ID  WORD 
LOC-_CPU  II      INTEGER 

VP_NR  WORD 

IDLE_VP  VP_INDEXJ 
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0000 


^SECTION  ITC_INT_PfiOC 
INTERNAL 
GETWORX  PROCEDURE 

*  SWAPS  VIRTUAL  PROCESSORS     * 
-  ON  PHYSICAL  PROCESSOR. 

jjt  sj:  as:  age  age  9  age  ap  j?  qc  aje  ay  ap  ags  ay  jjc  sj«  age  jjc  ap  ap  ap  ^s  a?  ajc  *s  sp  v  jjcj?  a,t 

*  PARAMETERS:  * 
R13:  LOGICAL  CPU  # 

REGISTER  USE:  * 

STATUS  REGISTERS  * 

Rl4:  DER  (SIMULATION) 
Rib:  STACK_POINTEfi 

LOCAL  VARIABLES: 


J* 

J? 

5? 


Rl 
R2 
R3 
R4 
R5 
R6 


READX_VP  (NEW) 
CURRENT  VP  (OLE) 
FLAG  CONTROL  WORD 
STACK_S£G  BASS  ADDR 
STATUS  REG  BLOCK  ACER 
NORMAL  S^ACK  POINTER 


a? 
a* 

5? 


•(C  Jyi  3|S  *i*  S|«  #|*  3y*  *|*  5f»  *y*  J,S  Jyi  i|*   *)*   ?,»  i^    »,*    r^.  i,»    i,J  *,i    ij4  ^, I  **£  *j&  *,»   ij*  J,C  *|*  »|S  #g*      f 

ENTRY 


0000  31E4 
0002  0004 

0004  3445 
0006  00F0 

0008  2F5F 

000A  7E32 
000C  3343 

000E  00F2 


!  GET  STACK  BASE  ! 

LD         R4,  R14(*STACK  SEG*4) 


LDA 


R5,  R4(*STATUS  REG  BLOCK) 


!  *  *  SAVE  SP  "  ! 
LD        (?R5,  R15 
I  =?  v    SA^E  FCW  *  *  ! 

LDCTL     R3,  FCW 

LD         R4(#F  C  W) ,  R3 


0010  61D1 
0012  0006' 


BOOTSTRAP_ENTF.Y:  !    GLOBAL    LAi^EL     ! 

!    GET~READY_VP    LIST    ! 
LD  Rl,    VPT. READY    LIST(R13) 


0014  4D11 
0016  0016' 

0018  FFFF 
001A  5E0E 
001C  0030' 
001E  4D11 
0020  0018' 
0022  FFFF 
0024  5E0E 


SELECT  VP: 

DO   !  UNTIL  SLGIBLE  READY  VP  FOUND  ! 
CP  VPT. VP. IDLE  FLAG (Rl),  *ON 


IF  EC   !  VP  IS  IDLE  !  THEN 
CP  VPT.VP.PREEMPT(Rl)  ,  #ON 

IF  EO   !  PREEMPT  INTERRUPT  IS  ON  !   THEN 
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0026  002C' 
e02S  5E08 

002A  003C' 

0e2C  5E08 
002E  0034' 
0030  5E09 
0032  003C' 


0034  6113 
0036  001C' 
0038  A131 
003A  E8EC 


003C  4D15 
003E  0014' 
0040  0000 
0042  6FD1 
0044  0002' 

0046  611E 
0048  0010' 


004A  31E4 
004C  0004 
004E  3445 
0050  00F0 

0052  215F 


0034  3143 
0056  00F2 
0058  7D3A 
005A  9E08 
005C 


EXIT  FROM  SSLECT_VP 

FI 
ELSE  !  VP  NOT  IDLE  ! 

EXIT    FROM    SELECT_V? 

FI 

!  GET  NEXT  READV_VP  ! 

LD   R3,  VPT.VP.NEXT_READT_VP(R1} 

LD   Rl,  P.3 
CD 

!  NOTE:  THE  READY_LIST  WILL  NEVER  BE 
THE  IDLE  VP,  WHICH  IS  THE  LOWEST 
WILL  NEVER  BE  REMOVED  FROM  THE 
IT  WILL  RUN  ONLY  IF  ALL  OTHER  FE£DV  VP'S 
IDLING  OR  IF  THERE  ARE  NO  OTHER  VP'S  ON 
THE  READT_LIST.  ONCE  SCHEDULED,  IT 
WILL  RUN  UNTIL  RECEIVING  A  HDWE  INTERRUPT 


!  NOTE:  R14  IS  USED  AS  D£R  HERE.  WHEN  MMU 

IS  AVAILABLE  THIS  SERIES  OF  SAVE  AND  LOAD 
INSTRUCTIONS  WILL  iJE  REPLACED  Ei    SPECIAL  I/O 
INSTRUCTIONS  TO  THE  MMU.  ! 

!  PLACE  NEW  VP  IN  RUNNING  STATE  ! 
LD    VPT.VP.STATE(Rl) ,  #RUNNING 


EMPTV  SINCE 
PRI  VP, 


LIST 


ARE 


LD    VPT.PUNNING_LIST(R13) ,  Rl 

!  -  -  SWAP  DBP  *  -  ! 

LD    R14,  VPT.VP.DBR(Rl) 


!  LOAD  NEW_VP  SP  ! 

LD    R4,  R14(#STACK_SEG*4) 

LDA   R5f  R4(*STATUS_REG_BLOCK) 

LD    R15,  GR5 

!  *  *  LOAD  NEW  FCW  *  -  ! 
LD    R3,  R4(#F_C_W) 

LDCTL   FCW,  R3 
RET 
END  GETWORK 
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005c 

Er 

vTER  msg  list                       PROCEDURE 

f  sps^Jis^jjc^jp^sis^spstJiCjpsje^jp^^^j.sspjis^jjtSis^SrJisv^sissP 

V 

INSERTS    POINTER    TO    MESSAGE 

* 

FROM    CURRENT    VP    TO    SIGNALED    VP* 

* 

IN    FIFO    MSG    LIST                                    * 

iji  *i*  *|»  *|»  ^*  *»*  *|»  *t*  *»*  *i»  *»*   *(»  *i*  *(*  *i»  *t*  *»*  *»*  *^  *I*    ***  *»"   *»*  *»*   *(*  *I*  *l"  "l*  'l*  *»*   *»'  *>*  *1* 

s? 

REGISTER   USE:                                          * 

V 

PARAMETERS:                                              * 

•i* 

R8(R9):MSG    (INPUT)                        * 

"r 

Rl:    SIGNALED    VP    (INPUTS             * 

5? 

R13:    LOGICAL~CPU    NUMBER             * 

V 

LOCAL    VARIABLES:                                  * 

* 

R2:    CURRENT   VP                                  * 

53 

R3:    FIRST    FREE    MSG                          * 

V 

R4:    NEXT   FREE    MSG                           * 

*e 

R5:    NEXT    Q   MSG                                  * 

V 

R6:    PRESENT    Q   MSG                           * 

*■«£  *i*  *.»  «i*  »!»  *»5  ijZ  *fi  #,i  it;  ;,c  afi  zfi  7fi  J,i  ^i  3,s  s^t  -^  2^s  ^i  ;,*  »,>  j^c  ;,i  sjc  ;,c  i,i  ;,j  #^«  *,;  i,;  *,»   j 

ENTRY 

005C 

61D2 

ID      R2,    VPT.RUNNING_LIST(R13) 

005E 

0002' 

!    GET    FIRST    MSG    FROM    FREE    LIST    ! 

0060 

6103 

LI 

00b2 

000A' 

j    sje    v   *    *    DEBUG    *    *  *    *    ! 

0064 

0E03 

CP    R3,    #NIL 

0066 

FFFF 

0068 

5E0E 

IF    EC    THEN 

006A 

0079' 

006C 

7601 

LDA   Rl,    S 

006E 

006C' 

0070 

2100 

LD    R0,    #M_L_0!    MESSAGE    LIST 

0072 

0004 

0074 

5F00 

CALL    MONITOR 

0076 

A900 

0078  6134 
007A  0122' 
007C  6F04 
007E  000A' 

0080  763A 
0082  0110' 

0094  2107 
0086  0010 
0088  BA81 
008A  07A0 


FI 

!  w  *  *  END  DEBUG  *  v  *    ! 

LD   R4,  VPT.MSG_0.N£XT_MSG(R3^ 
LD   VPT.FREE_LIST,  R4 

!  INSERT  MESSAGE  LIST  INFORMATION  ! 
LDA        R10,VPT.MSG_C.MSG(R3) 

LD        R7,#SIZE0F  MESSAGE 
LDIRB  0RlfcJ,(?R8,R7 
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008C  6F32     LD   VPT. MSG  0  .SENDER (R3  )  ,  R2 
008E  0120' 

!  INSERT  MSG  IN  MSG_LIST  ! 
0090  6115     LB   R5,  VPT . VP ,MSG_LIST f Rl  ) 
0092  0015' 

0094  0E05     CP   R5,  #NIL 

0096  FFFF 

0098  5E0S     IF  EO   !  ^SG  LIST  IS  EMPTY  !   THEN 

009A  00A4' 

!  INSERT  *SG  AT  TOP  OF  LIST  ! 
009C  6F13      LD  VPT.?P.MSG_LIST(Rl) ,  R3 
009E  001E' 

00A0  5E08     ELSE   !  INSERT  MSG  IN  LIST  ! 
00A2  00EC' 

MSG  Q_SEARCH: 

DO  ~!  '#HILE  NOT  END  OF  LIST  ! 
00A4  0B05      CP         R5,  #NIL 
00A6  FFFF 

00A8  5E0E      IF  EO   !  END  OF  LIST  !   THEN 
00AA  00B0' 

00AC  5E08      EXIT  FROM  MSG  0  SEARCH 
00AE  00B8' 

FI 

!  GET  NEXT  LINK.  ! 
00B0  A156      LD      R6,  R5 

00B2  6165      LD       R5,  VPT. MSG  C . NEXT_MSG( R6 ) 
00B4  0122' 
00B6  E8F6     OD 

!  INSERT  ^SG  IN  LIST  ! 
00B8  6F63     LD        VPT. MSG_0. NEXT_MSG( 86 ) ,  R3 
002 A  0122' 

FI 
00BC  6F35    LD        VPT. MSG  Q  .NEXT  MSG (R3 ) ,  R5 
00EE  0122' 
00C0  9E08     RET 
00C2       END  ENTER  MSG  LIST 
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00C2 


00C2 

00C4 


61D2 
0002 


GET_FIRST_MSG  PROCED 

*  REMOVES  MSG  FROM  MSG_1IST 

*  AND  PLACES  ON  FREE  LIST. 

*  RETURNS  SENDER'S  MSG  AND 

*  V?_ID 

-REGISTER  USE: 
-  PARAMETERS: 

*  Rd(R9):  MSG  POINTER  (INPUT) 

*  R13:  LOGICAL  CPU  NUMBER  ( INPU 

*  Rl:  SENDER  VP  (RETURNED) 

*  LOCAL  VARIABLES 


R2 
R3 

R4 
R5 

R6 


CURRENT  VP 

FIRST_MSG 
NEXT_MSG 
NEXT_FREE_MSG 
PRESENT  TREE  MSG 


URE 
T)* 


ENTRT 
LD 


R2,  VFT. RUNNING  LIST(R13) 


00C6 
00C8 


6123 

001E 


!  REMOVE  FIRST  MSG  FROM  MSG_LIST  ! 
LD         R3,  VPT.VP.MSG  LIST(H2) 


0-4?  C  A 
00CC 
00CE 
00D0 
00D2 
00D4 
00D6 
00D8 
00DA 
00DC 


0B03 
FFFF 
5E0E 
00DE 
2100 
0001 
7601 
00D6 
5F00 
A900 


I    *   v   v   v  DEEUG 
CP  R3,  #NIL 


^C   ;,i 


00DE  6134 
00E0  0122' 
00E2  6F24 
00E4  001E' 


00E6 
00E8 
00EA 
00EC 
00EE 
00F0 


6105 

000A' 

0E05 

FFFF 

5E0E 

0100' 


IF  EO  THEN 

LD  R0,  #M_1_EM   !  MSG  LIST  EMPTY  ! 

LDA  Rl,  $ 

CALL  MONITOR 

FI 

j    rf.   *   *    h;ND   jjiiBUG    *   *  *    ! 
LD  R4,    VPT.MSG_C.NEXT_MSG(R3) 

LD  VPT.VP.KSG_LIST(R2) ,    R4 

!     INSERT    MESSAGE    IN    FREE   LIST     ! 
LD  R5,    VPT.FREE_LIST 

CP  R5,    #NIL 

IF  EO    !  FREE  LIST  IS  EMPTY  !   TEEN 
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00F2  6F03 
00F4  000A' 
00F6  4D35 
00F8  0122' 
00FA  FFFF 
00FC  5E08 
00FE  011C' 


0100  0E05 
0102  FFFF 
0104  5E0E 
0106  010C' 
0108  5E08 
010A  0114' 


010C  A156 
010E  6165 
0110  0122' 
0112  E8F6 


0114  6F63 
0116  0122' 
0118  6F35 
011A  0122' 


!  INSERT  AT  TOP  OF  LIST  ! 
LD        VPT.FRSE  LIST,  R3 


011C 
011E 
0120 
0122 
0124 
0126 
0128 
012A 
012C 
012E 


6131 

0120' 

763A 

0110' 

2107 

0010 

BAA1 

0780 

9E08 


LD 


yPT.MSGJ}.N£XT_MSG(R3) t  #NIL 


ELSE   !  INSERT  IN  LIST  ! 

FREE_C  SEARCH: 
DO 

CP      R5,  sNIL 

IF  EO   !  END  OF  LIST  !   THEN 

EXIT  FROM  FREE_g_SEARCH 

FI 

!  GET  NEXT  MSG  ! 

LD  R6,  RS 

LD  R5,  VPT.MSG_C.NEXT_MSG(R6) 

OD 

!  INSERT  IN  LIST  ! 
LD        VPT.MSG  O.NEXT  MSG(R6),  R3 


LD 


VPT.MSG_0.NjlXT_MSG(R3)  ,  R5 


FI 

!  GET  MESSAGE  INFORMATION: 
(RETURNS  Rl:  SENDING_VP)   ! 

HI,  VPT.MSG  Q.SENDER(R2) 


LD 
LDA 
LD 
LDIRB 


R10,VPT.MSG_Q.MSG(R3) 
R7,#SIZE0F    MESSAGE 
yR8,OiR10tR7 


RET 
END  GET  FIRST  MSG 
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!   *  *  INNER  TRAFFIC  CONTROL  ENTRY  POINTS  *  v  ! 

!  NOTE:  AIL  INTERRUPTS  MUST  BE  MASKED  WHENEVER 
THE  VPT  IS  LOCKED.   THIS  IS  TO  PREVENT  AN 
EMBRACE  FROM  OCCURRING  SHOULD  AN  INTERRUPT 
OCCUR  WHILE  THE  VPT  IS  LOCKED.  ! 

GLOBAL 

SSSCTION  ITC_GLB_PROC 

PPEEMPT_R£T  LABEL 
KERNEL  EXIT  LABEL 
0000         CREATE_INT_VEC  PROCEDURE 

*  CREATES  ENTRY  IN  VIRTUAL  INT-* 

*  ERRUPT  VECTOR  WITH  ADDRESS    * 

*  OF  THE  VIRTUAL  INTERRUPT  FAN-* 

*  DLER.  * 

*  PARAMETERS:  * 

*  wl  :  VIRTUAL  INTERRUPT  #      * 

*  R2:  INTERRUPT  HANDIER  ADDR   * 

ENTRY 
!  COMPUTE  OFFSET  IN  VIRTUAL 
INTERRUPT  VECTOR  ! 
0000  1900     MULT       RR0,  *SIZEOF  ADDRESS 
0002  0002 

!  SAVE  ADDRESS  OF  VIRTUAL  INTERRUPT 
HANDLER  IN  INTERRUPT  VECTOR  ! 
0004  6F12     LD         VPT.VIRT_INT_VEC(R1)  f  R2 
0006  000C' 
0008  9E08     RET 
000A       END  CREATE  INT  VEC 
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eeeA      get  dbr  aedr        procedure 

*  CALCULATES  DER  ADDRESS  FROM   * 

*  DBR  NUMBER  * 

-  REGISTER  USE:  * 

*  PARAMETERS :  * 

*  R0 :  DBR  #  * 

-  RETURNS:  v 

*  Rl  :  DBR  ADDRESS  * 

ENTRV 
!  GET  BASE  ADDRESS  0?  MMU  IMAGE  ! 
000A  7601     IDA        Rl,  MMU_IMAGE 
000C  0000' 

!  ADD  DBR  HANDLE  (OFFSET)  TO  MMU  EASE 
ADDRESS  TO  OBTAIN  DBR  ADDRESS  ! 
000E  8101     ADD       Rl,  R0 

eeie  9E08   ret 

0012        END  GET  DBR  ADD?. 
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0012 


0012 
0014 


SD08 
8D18 


GET 


ALLOCATE_MMU  PROCEDURE 

ifi  Zfi  J?  J?  Tjt  3p  Vf.  3f( Jp  0?  S£  J?  7£  3}C  3(S  f  Sp  V  S?  V  >p  S?  Sp  *P  >P  Sp  >P  3p  V  *P  >P  ^ 

-  ALLOCATES    NEXT    AVAILABLE    MMU    * 

*  IMAGE   ANT    CREATES    PRDS    ENTRY    * 

-  REGISTER   USE:  * 

*  RETURNS  :  * 
R0:    DBR    #  * 

LOCAL    VARIABLES:  * 

Rl  :    SEGMENT    #  * 

R2:    PRDS    ADDRESS  * 

R3:    PRDS    ATTRIBUTES  * 

R4:    PRDS    LIMITS  * 

ENTRY 
!    GET    NEXT   AVAILABLE    DBR   #    ! 
CLR  R0 

CLR  Rl 

!    NOTE:    THE   FOLLOWING    IS    A    SAFE    SEQUENCE 

AS    NiJXT  AVAIL    *MU    AND    MMU    ARE    CPU    LOCAL! 
DBR: 
DO 


0016 

4C11 

0018 

0A00' 

001A 

0000 

001C 

5E0E 

001E 

002E' 

0020 

4C15 

0022 

0A00' 

0024 

FFFF 

0026 

5E08 

0028 

004A' 

0e2A 

5E08 

002C 

0048' 

002E 

A910 

0030 

0100 

0032 

0100 

0034 

0B01 

0036 

000A 

0038 

5E0E 

003A 

0048' 

003C 

2100 

003E 

0007 

0040 

7601 

0042 

0040' 

0044 

5F00 

0046 

A900 

CPB 


NEXT   AVAIL    MMU(Rl),    ^AVAILABLE 


IF    EO       !MMU    ENTRY    IS    AVAILABLE! 
THEN 

LDB      NEXT   AVAIL    MMU(Rl),    #ALLOCATED 


EXIT    FROM   GET_DBP 

ELSE       !CURRENT   ENTRY    IS    ALLOCATED! 

INC      Rl,    #1 

ADD      R0,    #SIZEOF    MMU 

J   ?   V   "r   *   JJgJ'Jg   vr   ?   ?   ?   | 

CP      Rl,    #MAX_DBR_NR 
IF    EO    THEN 

LD  R0,    #M_U       !MMU    UNAVAILABLE! 

LDA  Rl,    $ 

CALL  MONITOR 

FI 

!    *    *    *    END    DEBUG    *    *    *    ! 
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FI 


0048 

E8E6 

OD 

004A 

2101 

LD 

004C 

0000 

ee4£ 

7602 

LrA 

0050 

0A0A' 

0052 

2103 

LD 

0054 

0001 

0056 

2104 

LD 

0058 

0000 

Rl,  #PRDS_SEG         !    SEGMENT    NO. 

R2,  PRDS  !    PRDS    ADDR 

R3,  #1    !    READ   ATTR         ! 

R4,  #((SIZEOF   PRDS)-l)/256 


!    PRDS    LIMITS     ! 


005A  5F00 
005C  0060' 


005E  9E08 


0060 


!  CREATE  PRDS  ENTRY  IN  MMU  IMAGE  ! 
CALL       UPDATE_MMU_IMAGE   !(R1:  SEGMENT  # 

R2:  SEC-  ADDRESS 
R3:  ATTRIBUTES 
R4:  SEG  LIMITS ) ! 
RET 
END  ALLOCATE  MMU 
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0060 


UPDATE    MMU    IMAGE 


PROCEDURE 


J   V.VvvWSvvVV^vVvvVvVVtVV^^VV^tVV^V 


0060 
0062 
0064 
0066 
0068 
006A 
006C 

006E 
0070 
0072 
0074 
0076 
0078 
007A 

007C 
007E 
0080 
0082 
0084 
0086 
0088 
008A 
008C 

008E 
0090 
0092 
0094 


210A 
0000 
810A 
210D 
0004 
991C 
81DA 

2FA2 
A9A1 
0DA8 
2EAC 
A9A0 
20AC 
0A0E 
0808 
5E0E 
008A 
060C 
F7F7 
5E08 
00eE 
060C 
FEFE 

84EC 
2EAC 
9E08 


*  CREATES    SEGMENT    DESCRIPTOR 

*  ENTRY    IN    MMU    IMAGE 

2|C  *|*  *1*   »,»  2j/k   *,»   ZyZ.  »,»  i,i  J^i  «y«  3|C  Sj*  i,i  3,i  i^i  *g%   J,*    *,•  *|*    i,i  1,1    -,£  »ji  #,«  3fS   *,i  if*  * 


REGISTER    USE: 

PARAMETERS: 

R0:    DBR   # 

SEGMENT 
SEGMENT 
SEGMENT 
SEGMENT 


Rl  : 

R2: 
R3: 
R4: 
LOCAL 
R10: 


V 

5? 


ADDRESS 
ATTRIBUTES 
LIMITS 
VARIABLES: 
MMU    BASE    ADDRESS 
3:    OFFSET    VARIABLE 

ENTRV 
LD      R10,    #MMU    IMAGE    !    MMU    BASE    ADDRESS     ! 


* 
* 
'? 


ADD      R10,    R0 

LD      R13,    #SIZSOF   SEG 


DESC    REG 


MULT      RR12,    Rl    !    COMPUTE    SEG_DES.C 
ADD      R10,    R13    !ADD    OFFSET    TO    BASE 
!     INSEKT    DESCRIPTOR    DATA    ! 
LD      tfR10,    R2 
#2 


OFFSET    ! 
ADDRESS ! 


INC 
CLR 
LDB 
INC 

LDB 
CP3 


R10, 
CR10 
GR10 
R10, 
RL4, 
RL6, 


,    RL4 
#1 
OR10 


#i;(2)00001000    !    EXECUTE    ! 


IF      Eg      THEN 

ANDB      RL4,    #%(2)11110lll 
ELSE 

ANDB      RL4,    #%(2 )11111110 

FI 

ORB      RL4,    RL3 

LDB      (aRl0,    RL4 

RET 
END    UPDATE   MMU    IMAGE 


!     EXECUTE    MA5?    ! 


!    READ    MASK    ! 
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0094 


0094  7C0i 

0096    7604 
0098    0000' 
009A    5F00 
009C    0282' 


009E    5F00 
00A0    02C8' 


00A2    A11D 

00A4   61D2 
00A6    0002' 
00A8    6123 
00AA    001C' 

00AC    4D21 

00AE    001E' 
00B0   FFFF 
00B2    5E0E 
00B4    00EA' 


00B6  0E03 
00B8  FFFF 
00BA  5E0E 
00EC  00CA' 
00BE  2100 
00C0  0003 
00C2    7601 


HE 

Jpjp 


WAIT  PHOCEDU 

-  INT^A_KERNEL    SYNC/COM    PRIVATIVE 

*  INVOKED    BI    KERNEL    PROCESSES 

sp  sp  5p  sp  Sit  sp  ^s  sp  9  sp  sjs  ^«  ??  sp  sp  sp  ;gc  s?  sp  ^t sp  sp  3?  sp  sjc  sp  sp  sp  sp  sp  j?  ^  sp 

-  PARAMETERS 

*  RS(R9):    MSG    POINTER    (INPUTS 

*  Rl  :    SENDING_VP    (RETURN) 

*  GLOEAL    VARIABLES 

*  R14:    DBfi    (PARAM   TO   GETWORIH  * 

*  LOCAL    VARIA3LES  * 

-  R2:    CURRENT_VP    (RUNNING)  - 

*  R3:    NE7T_READY_VP  * 

*  R4:    LOCK  ADDRESS  * 

*  R13:    LOGICAL    CPU    NUMEER  * 

ENTRY 
!    MASK    INTERRUPTS    ! 
DI  VI 

!    LOCK    VPT    ! 
LDA  R4f    VPT.  LOCK 


CALL 


SPIN    LOCK       !     (R4:~VPT.LOCK)     ! 


!    NOTE:    RETURNS    WHEN    VPT    IS    LOCKEE    It    THIS    VF    ! 
!    GET    CPU    NUMBER    ! 
CALL  GET    CPU    NO       !  RETURNS: 


LD 
LD 
LL 

CP 


Rl :CPU   # 
R2:#    VP'S! 
R13,    Rl 

R2t    VPT.T?.UNNING_LIST(R13) 

R3,    VFT.VP.NEXT_READI_VP(R2> 

VPT.VP.MSG    LIST(R2),    #NIL 


IF    EC    !    CURRENT    VP'S    ^SG    LIST    IS    EMPTV    !    THEN 

!    REMOVE    CURRENT_VP    FROM   R£AEY_LIST    ! 
f    -v    v    v   v    DEBUG    *    :,:    *   -"!    ! 
CP  R3,    #NIL 

IF    EO      THEN 

LE      R0,    *R_L_E       !    REAEY    LIST    EMPTY    ! 

LDA    Rl,    $ 
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eec4 

00C6 
00C8 


00CA 

eecc 

00CE 
00D0 
00D2 


00D4 

eece 

00D8 

00DA 

00DC 


00  C2' 

5F00 

A900 


6FD3 
0006' 
4D25 
001C' 

FFFF 


4D25 
0014' 

0002 

612E 
0010' 


00DE  93F8 


00E0 

93FD 

00E2 

5F£0 

00E4 

0000' 

00E6 

97FD 

00E8 

97F8 

00EA 

5F00 

e0EC 

00C2' 

LD 
LD 


CALL  MONITOR 

FI 

!  *  *  *  END  DE£UG  *  *  *  ! 

7PT.READT_LIST(R13),  R2 

VPT. VP.  NEXT  READY  VP(R2,lf  #NIL 


!  PUT  IT  IN  WAITING  STATE  ! 
LD  VPT.VP.STAT£(R2)  t  ^WAITING 


!  SET  DPR  ! 

LD      R14,  7PT.VP.CPR(R2) 

!    SCHEDULE    FIRST    ELGIBLi   READV    VP    ! 

PUSH  GR15.R8 

!    SAVE   LOGICAL    CPU    #    ! 

PUSH  fJRlb,    R13 

CALL     GETWORK   !R13:C?U  * 

R14:DER! 

!  RESTORE  CPU  #  ! 

POP      R13,  G»R15 

POP        R8,(?R15 
FI 

!  GET  FIRST  MSG  ON  CURRENT  VP'S  MSG  LIST  ! 
CALL  GET_FIRST_MSG   !  COPIES  MSG  IN  MSG  ARRAy' 

!  R13:  LOGICAL  CPU  #  ! 
! RETURNS  Rl:  SENDER  VP  ! 


!  UNLOCK  VPT  ! 

00EE  4D08 

CLR   VPT. LOCK 

00F0  0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 
00F2  7C05     EI     VI 

!  RETURN:  RlrSENDER  VP  ! 
9E08     RET 

END  WAIT 


0eF4 
00F6 
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00F6        SIGNAL  PROCEDURE 

*  INTRA  KERNEL  STNC  /COM  PRIMATIVE  - 

*  INVOKED  PY  KERNEL  PROCESSES       * 

-  REGISTER  USE: 

*  PARAMETERS:  * 

*  R8(R9):  MSG  POINTER  (INFUT)     * 

*  Rl  :  SIGNALED  VP  ID  (INPUT)      * 

*  GLOBAL  VARIABLES  * 

*  R13:  CPU  #  (PARAM  TO  GETWORK )    * 

*  R14:  DBR  (PARAM  TO  GETWORK) 

*  LOCAL  VARIABLES:  * 

*  Rl:  SIGNALED  VP  * 

*  R2:  CURRENT  VP  * 

*  R4:  VPT. LOCK  ADDRESS  * 

ENTRT 
!  SAVE  VP  ID  ! 
00F6  93F1     PUSH    0R15,  Rl 

!  MASK  INTERRUPTS  ! 
00F8  7C01     DI     VI 

!  LOCK  VPT  ! 
00FA  7604     LDA        R4,  VPT.LOCK 
00FC  0000' 

00FE  5F00     CALL      SPIN_LOCK   !  (R4 :~VPT.LOCK)  ! 
0100  0282' 

!NOTE:  RETURNS  WHEN  VPT  IS  LOCKED  BY  THIS  VP.  ! 
!  GET  LOGICAL  CPU  #  ! 
0102  5F00     CALL       GET_CPU_NO  ! RETURNS: 
0104  02C8' 

El:  CPU  # 
R2  :  *    V?  'S  ! 
0106  A11D     LD         R13,  Rl 
!  RESTORE  VP  ID  ! 
0108  97F1     POP        Rl,  (?Rl5 

!  PLACE  MSG  IN  SIGNALED_V? 'S  MSG_LIST  ! 
010A  5F00     CALL  ENTER  MSG_LIST  !(R8:MSG  POINTER 
010C  005C'  Rl:SIGNALED_VP 

Rl?:LOGICAL  CPU  #)  ! 

010E  4D11     CP        VPT.VP.STATE(R1  )  ,  ^WAITING 

0110  0014' 

0112  0002 

0114  5E0E     IF  EO   !  SIGNALED_VP  IS  WAITING  !   THEN 

0116  0148' 

!  WAKE  IT  UP  AND  MAKE  IT  READY  ! 
0118  A112       LD       R2,  Rl 
011A  76D3       LDA      R3,  VPT .READ*_L1ST (R13 ) 


211 


011C 

0006' 

011E 

7604 

0120 

eeic' 

0122 

7605 

0124 

0012' 

ei26 

7606 

0128 

0014' 

012A 

2107 

012C 

0001 

012E 

93FD 

0130 

5F00 

0132 

0000* 

0134  97FD 


0136 
0138 
013A 
013C 
013S 

0140 

0142 


61D2 
0002 

4D25 
0014 
0001 

612E 

0010 


LDA  R4,  VPT.VF.NEXT_R£ADY_VP 

LDA  R5,  VPT.VP.FRI 

LDA  Rti,  VPT.VP. STATS 

LD  R7,  #RSADV 

!  SAVE  LOGICAL  CPU  #  ! 

PUSH  tfP.15,  R13 

CALL  LIST  INSERT   !R2:  OBJ    ID 


LIST  FTP  AL'CP. 


R4: 

NEXT  OEJ  PTR 

R5 

:  PRIORITY  FTP. 

R6 

:  STATE_FTR 

R7: 

STATE   ! 

!    RESTORE   LOGICAL    CPU   #    ! 

POP  R13,    GR15 

!    PUT    CURRENT    VP    IN    READ1?'   STATE    ! 
LD  R2,    VPT. RUNNING    IlST(R13N 


LD 


VPT.VP. STATE (R2)  ,  #READ7 


!  SET  D2R  ! 

LD        R14,  VPT.VP.DBR(RiM 


0144 
0146 


5F00 
0000 


0148 
014A 


4D08 
0000 


014C  7C05 

014E  9E08 
01S0 


!  SCHEDULE  FIRST  ELGIELE  READY  VP  ! 
CALL    GETWORK   !R13:I0GICAL  CPU  ft 

P14:DBR  ! 
FI 

!  UNLOCK  VPT  ! 
CLR   VPT. LOCK 

!  UNMASK  VECTORED  INTERRUPTS  ! 
EI     VI 

RET 
END  SIGNAL 
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0150  SET   PREEMPT  PROCEDURE 

*  SETS    PREEMPT    INTERRUPT    ON* 

*  TA?GET_VP.    CAIIED    BY    TC_    * 

*  ADVANCE.  * 

i,:  ?p  'i»  *£>£  i?  2,*  ^r  1*  ^  *t»  *i?  5^  *?  *r  *r  V  *J»  *?*i*  V  '•»  1*  2£  3£  2,1  J,;  i^ 

-  REGISTER    USE:  * 

*  PARAMETERS :  * 

*  Rl : TARGET   VP    I E    (INPUT)    - 

-  LOCAL    VARIABLES  * 

*  Rl:    VP_ INDEX  * 

^C5^  5?  n*5£  J£  ^CSii^i  V  J^  ^  3£  ^i  ^i  2£*r  *?  ^*£  *^  ~fi  *i*  5^  *£  V  *i*  *i;   I 

ENTRT 
!    NOTE:    DESIGNED    AS    SAFE    SEQUENCE    SO    VFT    NEED 
NOT    BE   LOCKED.     ! 

!    CONVERT    VP_ID   TO   VP    INDEX    ! 
R2,    EXT    VP    LIST(R1^ 


ON    TGT_VP    PREEMPT    FLAG    ! 
VPTTVP. PREEMPT ( R2 ) ,    #ON 


!    **    IF    TARGET    VP    NOT    LOCAL 

(    NOT    BOUND   TO    THIS    CPU    ) 
[IE,    IF    «CPU_SEG»CFU_IDOVFT.VF.FHYS_CPU(:3.l)J 
THEN    SEND    HARDWARE    PREEMPT    INTERRUPT    TO 
VPT.VP.CPU(Rl)  .    **    ! 


0150 

6112 

LD 

0152 

0210' 

!    TURN 

0154 

4D25 

LD 

0156 

0018' 

0158 

FFFF 

015A    9E08  RET 

015C  END    SET    PREEMPT 
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015C 


IDLE 


PROCEDURE 


|  rt+  •»»  *(•  *|*  »!»  *,»  »|*  »|»  »|5  •)»  5^  *y»  #j*  ^5  »(•  »(*  J(J  J^%  *(*  »]•  *|*  *(%  *|» 

;.: ;,: 

3? 

LOADS    IDLE    DER    ON 

* 

^ 

CURRENT    VP.    CALLED    BY 

;? 

V 

TC    GETWO^K. 

V 

^yt*^^3fi^^Xt#xt*st3?**ifiVfi****ifi*fi 

^r 

REGISTER    USE 

T« 

n* 

GLOBAL   VARIABLE 

-.« 

5? 

R13:    LOG    CPU   # 

¥ 

J? 

F14:    EBR 

5? 

sge 

LOCAL    VARIABLES: 

V 

5? 

R2:    CURRENT    VP 

* 

* 

R3:    TEMP   VAS 

5? 

•P 

R4:    VPT.LOCK    ADDR 

V 

=* 

R5:    TEMP 

*< 

:?  s^  ^  ;,cjs  ^t  ^  j^  v  xx  ;^  >;;  ;?  ^«  "  r^  r,s  x,;  ^i j£  ^:  ^c  v  >?  s,<  f 

ENTR? 

'    GET    LOGICAL    CPU   #    ! 

015C    5F00           CALL                GET    CPU   NO 

! RETURNS 

0174    6103 
0176    0A10' 
0178    6135 
017A    0010' 
017C    6F25 
017E    0010' 


0180    4D25 

0182  eei6' 

0184    FFFF 

0186    4D25 
0188    0014' 
018A    0001 


!    LOAD    IDLE   DER    ON    CURRENT    VP    ! 
LD  R3,    PRDS.IDLE_VP 


LD 
LD 


R5,    VPT.VP.DER(R3) 
V?T.VP.DBR(?.2),    R5 


!    TURN    ON    CURRENT    VP'S    IDLE    FLAG    ! 
LD  VPT.VP.IDLE    FLAG(R2)t    *ON 


!    SET    VP    TO    READY    STATE    ! 

LD  VPT.VP.STATE(R2^ ,    #REAET 


018C    5F00 
018E    0000' 


0190   4D08 
0192    0000' 

0194   7C05 


!    SCHEDULE    FIRST    ELIGIBLE    READY    VP    ! 
CALL         GETWORK       ! R13:IOGICAL    CPU    # 

R14:DBR    ! 

!    UNLOCK    VPT    ! 
CLR      VPT.LOCK 

!    UNMASK   VECTORED    INTERRUPTS     ! 
SI  VI 


0196    9E08 
0198 


RET 
END    IDLE 
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0198  SWAP   VDBR^  PROCEDURE 

*  LOADS    NEW    DBR    ON  * 

*  CURRENT    VP.    CALLED    3Y    * 
-   TC_GETWORK. 

*  REGISTER    USE  * 

*  PARAMETERS  v 

*  RU    NEW    DBR    (INPUT)    * 

*  GLOBAL  VARIABLES      * 

R13:  LOGICAL  CPU  #   - 

*  R14:  DBR  * 

*  LOCAL  VARIABLES       * 

R2:  CURRENT  VP      - 

*  R4:  VPT.LOCK  ADDR    * 

ENTRT 

!    SAVE  NEW    Di3R    ! 
0198   93F1           PUSH  PR15,    Rl 

!  MASK  INTERRUPTS  ! 
019A  7C01     DI     VI 

!  LOCK  VPT  ! 
019C  7604     LDA        R4,  VPT.LOCK 

ei9E  eeee' 

01A0  5F00     CALL       SPIN_LOCK   !  (R4 :~VPT . LOCK )  ! 
01A2  0282' 

!  NOTE:  RETURNS  WHEN  VPT  IS  LOCKED  BY  THIS  VP.! 
!  GET  CPU  #  ! 
01A4  5F00     CALL       GET_CPU_NO   ! RETURNS: 
01A6  02C8' 

Rl :  CPU  # 
R2:*  VP'S! 
eiA8  A11D     LD         R13,  Rl 

!  GET  CURRENT  VP  ! 
01AA  61D2     LD         R2 ,  VPT  .RUNN  ING_LIST  (Rli5 ) 
01AC  0002' 

j  ^s  :?  v  DEBUG  *  *  *  ! 
01AE  4D21  CP  VPT. VP.MSG  LIST (R2),  *NIL 

0iij0  eeis' 

01B2  FFFF 

01B4  5S06  IF  NE  !  MSG  WAITING  !   THEN 

01B6  eiC4' 

01B8  2100  LE   R0,  #S  N  A   !  S'*AP  NOT  ALLOWED  ! 

01BA  0005 

01BC    7601  LDA    Rl  ,    $  IPC  ! 

01BE    01BC 

01C0  5F00  CALL  MONITOR 

01C2  A900 

FI 

!  -  *  END  DEEUG  *  ~-    ! 
!  SET  DBR  ! 
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eiC4  61??,  LD        R14,  VPT.VP.DER(R2l 

01C6  0010' 

!  RES  TOR  i'  NEW  DBF  ! 
eiCS  97F0     POP        R0,  GH15 

01CA  5E00    CALL      GET_DER_ADDR    !  (R0:  IBP  ff) 
01CC  000A' 

RETURNS 
(Rl:  EBR  AEER)  ! 

!  LOAD  NEW  DBF  ON  CURRENT  VP  ! 
01CE  6F21     LD         VPT .  VP  ,DBR(  R2  >  ,  Rl 
01D0  0010' 

!  TURN  OFF  I  DIE  FLAG  ! 
01D2  4P25     IE         VPT  .  VP  .  IDIEFIAG  (  R2  ),  ?CFF 
01D4  0016' 

01D6  0ee0 

!  SET  VP  TO  READY  STATE  ! 
01D6  4P25     LD         VPT .VP .STATE ( R2  )  .  *REAEI 
01DA  0014' 
01DC  0001 

!  SCHEDULE  FIRST  ELGIBLE  READ!  VP  ! 
eiDE  bFe0     CALL    GETWORK   !R13:I0GICAL  CPU  * 
01E0  0000' 

R14:DBR  ! 

!  UNLOCK  VPT  ! 
01E2  4D08     CLR   VPT. LOCK 
P1E4  0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 
01E6  7C05     EI     VI 

01E8  9E08     RET 

Z1EA        END  SWAP  VDBR 
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eiEA  PHYS_PREEMPT_HANDLER         PROCEDURE 

I  ^z  %<■  *fi  *c  zt  zt  ^  3£  v-~2,=  :.:  spa?  ^r,;:?:,;  r,;  v  ??  *,: :;;  ~,;  ^  ^< -,:  ^  V  ',=  V^' 

•"  HARDWARE   PREEMPT    INTEPRUFT  * 

*  HANDLER.       ALSO    TESTS    FOR  * 

*  VIRTUAL    PREEMPT    INTERRUPT  * 

*  FLAG   AND    INVOKES    INTERRUPT 

-  HANDLER    IF    FLAG    IS    SET.  * 

-  INVOKED   UPON    EVERY    EXIT    FROM  * 

*  KERNEL.      KERNEL    FCW    MASKS 

*  NVI    INTERRUPTS    TO    PREVENT  * 

*  SIMULTANEOUS    PREEMPT    INTiRR.  * 
'•s    HANDLING. 

*  REGISTER    USE  - 

-  LOCAL    VARIABLES  * 

*  Rl:    FREEMPT    INT_FIAG  * 

*  R2:    CURRENT  JT?  * 

*  GLOBAL    VARIABLES  * 

*  R13:I0GICAL   CPU   #  * 

*  F14:DB?  * 


ENTRY 

i    *   *    FREEMPT_HANDLER    *   *    ! 

!    SAVE   ALL    REGISTERS     ! 
01EA    030F  STTF  R15,    #32 

01EC    0020 

01EE    1CF9  LDM  0R15,    Rl ,    #16 

01F0    010F 

!    SAVE    NORMAL    STACK    POINTER    (NS?)     ! 
01F2   7D67  LDCTL  R6,    NSP 

01F4   93F6  PUSH  PR15,    R6 

!    GET    CPU    *    ! 
*>1F6    5F00  CALL  GET_CPU    NO    'RETURNS: 

01FB    02C8' 

Rl  :    CPU    n 
R2:#   VP'S  ! 
01FA   A11D  LD  R13,    Rl 

!    MASK    INTERRUPTS     ! 
01FC    7C01  DI  VI 

!    LOCK    VPT    ! 
01FE   7604  LDA        R4,    VPT. LOCK 

0200    0000' 

0202    5F00  CALL      S?IN_LOCK 

0204    0282' 

! RETURNS    WHEN    VPT    IS    LOCKED! 

!    SET    DEB.    ! 
0206    61D2  LD  R2,    VPT. RUNNING    LIST(R13) 
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2206  0002' 

020A  612S     LD  '  R14,  VPT .VP .DER (R2 ) 

020C  2010' 

!  PUT  CURRENT  PROCESS  IN  READY  ST!TF.  ! 
020E  4D25     LD        VPT  .  VP. STATE  (R2  )f  #HJ£AEY 
0210  0014' 
0212  0001 

0214  bF02     CALL      GETiCRK   !R13:L0G  CPU  # 
0216  0000' 

R14:LER  ! 

PREEMPT  RET: 

!  UNLOCK  VPT  ! 
0218  4D08     CL*     VP^.LOCK 
021A  0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 
021C  7C05     EI     VI 

KERNEL  EXIT: 

»  www  UNMASK  VIRTUAL  PREEMPTS  ***  f 
!  ww  NOTE:  SAFE  SEQUENCE  AND  EOES  NOT  REQUIRE 
VPT  TO  BZ    LOCKED.  --  ! 

!  GET  CURRENT_VP  ! 
021E  610D     LD     R13,  PRDS.LOG_CPU  ID 
0220  0A0C' 

2222  61D2     LD  R2,  VFT. RUNNING  LIST(R13^ 
0224  0002' 

!  TEST  PREEMPT  INTERRUPT  FLAG  ! 
0226  4D21     CP       VPT.VP.PREEMPT(R2^  ,  #ON 
022B  0018' 
022 A  FFFF 

022C  5E0E     IF  SO   !   PREEMPT  FLAG  IS  CN  !   THEN 
022E  0240' 

!  RESET  PREEMPT  FLAG  ! 
2230  4D25        LD    VPT. VP .PREEMPT (R2 ),  *OFF 
0232  0018' 
0234  2000 

!  SIMULATE  VIRTUAL  PREEMPT  INTERRUPT  ! 
0236  2101        Ld        Rl,  #2 
0236  0200 

223A  6112        LD    R2,  VPT . VIRT_I NT_VEC ( Rl ) 
023C  000C' 
023E  1S28        JP    @R2 

!NOTE:  TEIS  JUMP  TO  TRAFFIC_CONTROl 
IS  USED  ONLY  IN  THE  CASE  OF  A  PREEMPT  INTERRUPT, 
AND  SIMULATES  A  HARDWARE  INTERRUPT.  --  ! 

!  www  £ND  VIRTUAL  FREEMPT  HANDIER  www  j 
FI 
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!  NOTE:  SINCE  A  HDWE  INTERRUPT  DOES  NOT  EXIT 
THROUGH  THE  GATE,  THOSE  FUNCTIONS  PROVIDED 
21    A  GATE  EXIT  TO  HANDLE  PREEMPTS  MUST  BE 
PROVIDED  HERE  ALSO.  ! 


!  RESTORE  MSP  ! 

^240 

9?Fb 

POP  RS,  PR15 

0242 

7D6F 

LDCTI    NSP,  R6 

!  RESTORE  ALL  REGSTERS 

£244 

1CF1 

LDM      Rl,  (?Rlb,  #16 

0246 

010F 

0246 

010F 

ADD       R15,  #32 

£24  A 

0020 

!  EXECUTE  HARDWARE  INTERRUPT  RETURN  ! 
024C  7B00    IRET 

024E      END  PfiYS  PKEEMPT  HANDLER 
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£24£  RUNNING   VP  PROCEDURE 

I   »(■*  3t%   *^»  ^*  i,5  J,*  «>^i  #l«  *,i  J,C  »,i  i,i  7|C  *,i  *,£  *,i  *,C  »,»  »,*  *,S  ?, «  i|i  *,»  »,i  »,»  -,»  J, «.  J,C  3JJ  »  ; "  «,i  »,£  i,» 

*  CALLED    £Y    TRAFFIC    CONTROL.  * 

-  RETURNS    ^TP    ID.    RESULT    IS    VALID* 

-  ONLY    WHILE   APT    IS    LOCKED. 

*  REGISTER   USE  * 
:!      PARAMETERS                                                * 

*  Rl:    ill1:    VP_IE       (RETURNEE)         - 

*  R3:    LOG~CPU    #    (RETURNEE)  * 

*  LOCAL    VARIAELES  * 

*  R2:    VP    INDEX  * 

3gS  J<c  3J<  3£  v  ^  Si'-  J"^  ^*  ^  *,i  ^;  ^  ^  )?  ;*  ^;  ^;  ^s  /;;  ^  ^  ^i  ^.  ;^  ^  ^:  ^  ^  v  ^c  ?;x  f 

ENTRY 

!    MASK    INTERRUPTS     ! 
024E   7C01  DI  VI 

!    LOCK    VPT    ! 
0250    7604-  LDA  R4,    VPT. LOCK 

0252    0000' 

0254  5F00  CALL  SPIN_LOCK       !     (R4  :'~7PT  .  LOCK  )     ! 
0256    0282' 

!     NOTE:    RETURNS    VHEN    VPT    IS    LOCKED    BY    THIS    VP    ! 
!    GET    LOGICAL    CPU    #    ! 
0258    5F00  CALL  GET_CPU_NO       ! RETURNS: 

025A    02C8' 

Rl:    CPU   # 
R2:#    VP'S! 
025C    A113  LD  R3,    Rl 

0255  6132  LD  R2 ,    VPT. RUNNING    LIST(R2) 
£260    0££2' 

!    CONVERT    VP_INEEX    TO    V?_1E    ! 
0262   6121  LD  Rl ,    VPT .VP .EXT_IE (R2 ) 

0264    0£20' 

»    *    *   *    DEBUG    *   *   *    ! 
2266    0E01  CP      Rl.    #NIL 

0268    FFFF 

026A    5E0E  IF    EQ       !    KERNEL    PROC    !       TEEN 

026C    027A' 

026E    2100  LD    R0,    #V    I    E       !    VP    INDEX    ERROR     ! 

0270    0006 

0272    7601  LDA    Rl ,    S 

£274    0272' 

0276    5F00  CALL    MONITOR 

0278    A900 

FI 

!    *    *    END    DEBUG    *    *    ! 

!    UNLOCK    VPT    ! 
027A   4D08  CLR  VPT. LOCK 

027C    0K00' 

!    UNMASK    VECTORED    INTERRUPTS     ! 
027E   7C05  EI  VI 

0280    9E08  RET 

0282  END   RUNNING    V? 
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0282  SPIN    LOCK        PROCEDURE 

*  USES    SPIN_LOCK    MECE.       * 

*  LOCKS    UNLOCKED    DATA 

*  STRUCTURE    (POINTED    TO    * 

*  BY    INPUT    PARAMETER).       * 

;,;;,;  ^  J  ;,c  #,;  jgi  j,;  ;,;  ;,;  3,;  %z  5,;  :,;  ;,;  *,i  ^j  ;,s  j^c  i,i  •,?  7fi  ;,;  J^  *,!  ;., '- 

^REGISTER   USE  * 

*  PARAMETERS  * 
-      P4:    LOCK    ADDR    (INPUT)- 

ENTRY 

!       NOTE:    SINCE    ON  L^    ONE    PROCESSOR    CURRENTLY 
IN    SYSTEM,    LOCK    NOT    NECESSARY.    **    ! 

j   ss:  j*  j*  JJEJUQ  ^  t  ?  J 

CP      PR4,    *OFF 

IF    NE    !    NOT    UNLOCKED    !       THEN 

LD      Re,    #U_L  !    UNAUTHORIZED    LOCK    ! 

LDA    Rl ,    S 

CALL    MONITOR 

EI 

!    *   *    END    DE-fcUG    *    *    ! 
TEST_LOCK: 
!       DO    WHILE    STRUCTURE    LOCKED    ! 
0296    0D*6  TSET  GR4 

0298    E5EE  JR    MI,    TEST_LOCK 

!    v*    NOTE    SEE    PLZ/ASM    MANUAL 
FOR    RESTRICTIONS    ON 
USE    OF    TSET.    **    ! 
029A   9E08  RET 

029C  END    SPIN    LOCK 


0282 

0D41 

0284 

0000 

0286 

5E06 

0288 

029b 

028A 

2100 

028C 

0000 

028S 

7b01 

0290 

026E 

0292 

5E00 

0294 

A900 
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029C  ITC_GST_SEG_PTR  FROCEDURE 

J    J,i  *|4  3|i  JJC JjS  3JS  i|»  #^5  ?^C  ?il  JJ5  5J»  2|C  i|C  J^i  5^C  *f«  ^i  »J5  JJ%  J"(J  »p  »i»  »,i  3JC  3J?  *,%  *]*  *^*  Jjl  3p  ![»  i,i 

*  GETS    EASE   ADDRESS    OF    SEGMENT      * 

*  INDICATED.  * 

J,"?  ?£  J!*  3QC  5^  9QC  5£  *;»  >JC  3£  V  3J8  V  *£  Is  1*  *£  3QC  *»»  3j*  5J*  3QC  3J6  3^  3}i  >|C  5£  ^S  3JC  5£  3QC  SJC  Sp 

*  REGISTER    USE:  - 

*  R0:SEG    BASE    ADDRESS  (RET  )  * 

*  RltSEG    NT?    (INPUT) 

'■•'  R2: RUNNING    VP    (LOCAL) 

*  R3:D£R  VALUE    (LOCAL)  * 

*  R4:  VPT.  LOCK  * 

*  R13  .'LOGICAL    CFU    tt 

ENTRY 

!    SAVE   SEGMENT   ft    ! 
029 C    93F1  PUSH  OR  lb,    Rl 

!    MASK    INTERRUPTS     ! 
029E   7C01  DI  VI 

!    LOCK    VPT    ! 
02A0    7604  LDA  R4, VPT. LOCK 

02A2    0000' 

02A4    5F00  CALL  SPIN_LOCK       ! R4  :"VPT . LOCK  ! 

02A6    0292' 

02AB    5F00 
02AA    02C8' 


!    GET    CPU    #    ! 
02A8    5F00  CALL  GET    CPU    NO       IRETURNS: 


Rl  :    CPU   # 
R2:#    VP  'S  ! 
02AC    A11D  LD  PI 3,    Rl 

!    RESTORE    SEGMENT    *t    ! 
02AE   97T1  POP  Rl,    G>R15 

02B0   61D2  LD  R2, VPT. RUNNING    LIST(R13) 

02B2    0002' 

02B4   6123  LD  R3 , VPT . VP .DBR ( R2 ) 

02B6    0010' 

!    UNLOCK    VPT    ! 
02B8    4D08  CLR  VPT. LOCK 

02BA    0000' 

!    "NMASK    VECTORED    INTERRUPTS     ! 
02BC    7C05  EI  VI 

02BE    1900  MULT  RR0,#4 

02C0    0004 

02C2    7130  LD  R0,R3(R1) 

02C4    0100 

02C6    9E08  RET 

02C8  END    ITC    GET    SEG    PTR 
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02CS  GET    CPU    NO  PROCEDURE 

*  FIND    CURRENT    CPU_NO         * 

-  CALLED    BT    DIST    MMGR 

*  AND    MM  * 

3£  3?  33S  ',i  V  t*  3^  ^  5?  ^  3,c  v  ;^  3?  3,5  3?  v  ^  3?c  v  *,*  3,;  v  -;'  3£ 

*  RETURNS  * 

-  Hi:    CPU_NO  * 

*  R2:    #   OP   VP'S  * 

3^«  3|5  3JC  3,C  3,*  3,£  3,4  if*  *|i  3jS  3,1  3,5  -,i  3,*  »,»  2^*  #,;  *,5  3,*  3,«  3,*  3,C  3,i  J,.  3|*   T 

ENTRY 

02C8    6101  LD  HI,    PRDS  .LOG_CPU_ID 

02CA    0A0C' 

02CC    6102  LD  H2,    PRDb.VP_NR 

02C£    0A0S' 

02D0    9E08  RET 

02D2  END  GET    CPU    NO 


02D2  K_LOCK  PROCEDURE 

f  »|{3ifi  SQS  3g»3^S  3Q6  JQ(3j(9gS3|C  8{E  3|C3^X  9QC  9JC  3,;  3,;  3,;  ;,;^i  ;;«  ^1  3,;  -,-;,; 

*  STUii    FOR    *AIT    LOCK         * 

3|C  3;*  9QC  3^3|C  33^3^3^3^3^3^3^3;C33:3^3^3|C3^3^33S3f%3^3'(C3^3^ 

*  R4:"lOCK    (INPUT)  * 

jpjjcjjjjp^jicj^jp  spa?  a;:  >*:?"* ^cs^sjcj^^tjjt^cjiejp^t^t  J 

ENTRY 
02D2    5P00  CALL      SPIN_LOCK 

02D4    02S2' 
02D6    9E08  RET 

02D8  END    K    LOCK 


£2D8  KJJNLOCK  PROCEDURE 

l    5J6  3Ji  35>  2^  ^  53*  3)C  3^£  3JS  3Ji  3^  3^i  33*  3J5  3J»  33>  i^C  3jC  3JC  3f%  3\S  33!  33*  3,C  3^C 

*      STUB    FOR    WAIT    UNLOCK    * 

5£  t£  sp  ggogi  ^t  jp  jjc  ap  ^1  ^c  sje  jjc  ^t  3^  sjc  jjc  ^c  jjc  jjs  3?  J?  ;?  jp  ^e 

v      R4:~LOCK    (INPUT)  * 

• 

ENTRY 
02D8    0D48  CLR        C°P4 

02DA   9E08  RET 

02DC  END    KJJNLOCK 

END    INNER    TRAFFIC    CONTROL 
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